Patchwork --enable-linker-build-id by default

login
register
mail settings
Submitter Roland McGrath
Date Oct. 5, 2010, 5:09 a.m.
Message ID <20101005050958.3841D401B2@magilla.sf.frob.com>
Download mbox | patch
Permalink /patch/66750/
State New
Headers show

Comments

Roland McGrath - Oct. 5, 2010, 5:09 a.m.
It benefits all of us to have as many user binaries as possible built
with build IDs.  Any time a user has a binary or a core file and one
of us is asked to help figure out some problem, we can take advantage
of the possibilities to match up build IDs with known binaries.  Many
system builders for GNU/Linux are enabling them now, but there will
always be some system builders who don't know to do so, and people and
organizations that build their own compilers with mostly-default
configure settings, and we still wind up having to help these people.
There is nothing inherently specific to GNU/Linux about the benefits
of build IDs, so this applies to any other target just as well when
the target's linker supports it.

Let's make it the default for everyone who doesn't ask especially not
to have it at configure time, when the configure-time linker supports it.

Some unusual programs (usually those with custom linker scripts) might
have problems with the build ID note, but the common examples of those
in free software have been fixed already.  Any system builder or
anyone else concerned with compatibility for those situations can
always use --disable-linker-build-id (or -Wl,--build-id=none in a
particular compilation).

I've tested that 'make bootstrap; make check' has no regressions from
this change, but I only tested on x86-64 on a GNU/Linux system where
the system's compiler already uses build IDs by default (Fedora 13).

(Remember, I'm not a GCC committer, so someone approving this will
have to commit it for me too.)


Thanks,
Roland


2010-10-04  Roland McGrath  <roland@redhat.com>

	* configure.ac (--enable-linker-build-id): Default to yes if
	the linker supports it.
	* configure: Regenerated.
	* doc/install.texi (Configuration): Document new default.
Daniel Jacobowitz - Oct. 5, 2010, 2:31 p.m.
On Mon, Oct 04, 2010 at 10:09:58PM -0700, Roland McGrath wrote:
> Some unusual programs (usually those with custom linker scripts) might
> have problems with the build ID note, but the common examples of those
> in free software have been fixed already.  Any system builder or
> anyone else concerned with compatibility for those situations can
> always use --disable-linker-build-id (or -Wl,--build-id=none in a
> particular compilation).

FYI.  The last time I tried this, given how GNU ld handles orphan
placement, this broke every embedded linker script I had handy to
check against.  It's a failure which won't show up in typical
toolchain testing, either.  The note ended up at zero, instead of
whatever else (e.g. an interrupt vector) was supposed to be there.

Expect a bit of fallout.
Paolo Bonzini - Oct. 5, 2010, 2:36 p.m.
On 10/05/2010 07:09 AM, Roland McGrath wrote:
> It benefits all of us to have as many user binaries as possible built
> with build IDs.  Any time a user has a binary or a core file and one
> of us is asked to help figure out some problem, we can take advantage
> of the possibilities to match up build IDs with known binaries.  Many
> system builders for GNU/Linux are enabling them now, but there will
> always be some system builders who don't know to do so, and people and
> organizations that build their own compilers with mostly-default
> configure settings, and we still wind up having to help these people.
> There is nothing inherently specific to GNU/Linux about the benefits
> of build IDs, so this applies to any other target just as well when
> the target's linker supports it.
>
> Let's make it the default for everyone who doesn't ask especially not
> to have it at configure time, when the configure-time linker supports it.

Alex, can this do something bad to bootstrap-debug?  I wonder if having 
different -g settings for stage2 and stage3 would cause different build 
IDs and ultimately cause a comparison script.

Can you check and commit it for Roland if it is fine, or otherwise work 
out together something that will work?

Paolo
Roland McGrath - Oct. 5, 2010, 7:37 p.m.
> Alex, can this do something bad to bootstrap-debug?  I wonder if having 
> different -g settings for stage2 and stage3 would cause different build 
> IDs and ultimately cause a comparison script.

Different output of any kind (including DWARF and symbol tables) in the
final linked binaries will produce different build IDs, yes.  It should be
easy enough to ignore those in comparisons.  IIRC there is some similar
situation already for ignoring timestamps or something, but I don't really
know where all the comparison stuff is.

Thanks,
Roland
Roland McGrath - Oct. 5, 2010, 7:39 p.m.
> FYI.  The last time I tried this, given how GNU ld handles orphan
> placement, this broke every embedded linker script I had handy to
> check against.  It's a failure which won't show up in typical
> toolchain testing, either.  The note ended up at zero, instead of
> whatever else (e.g. an interrupt vector) was supposed to be there.

Sure, there can be some issues.  We went through several such things
when we first deployed build IDs in Fedora, and various things got fixed
up.  On occasion someone will just decide that -Wl,--build-id=none is
the most sensible thing for their particular situation.  

> Expect a bit of fallout.

People who object can always use --disable-linker-build-id, of course.
Certainly the subject merits some release notes advice.


Thanks,
Roland
Daniel Jacobowitz - Oct. 5, 2010, 7:45 p.m.
On Tue, Oct 05, 2010 at 12:39:38PM -0700, Roland McGrath wrote:
> > FYI.  The last time I tried this, given how GNU ld handles orphan
> > placement, this broke every embedded linker script I had handy to
> > check against.  It's a failure which won't show up in typical
> > toolchain testing, either.  The note ended up at zero, instead of
> > whatever else (e.g. an interrupt vector) was supposed to be there.
> 
> Sure, there can be some issues.  We went through several such things
> when we first deployed build IDs in Fedora, and various things got fixed
> up.  On occasion someone will just decide that -Wl,--build-id=none is
> the most sensible thing for their particular situation.  

Yes, for a Linux target this is what I'd expect: a small handful of
affected projects.  I'm just asking the community to keep in mind that 
the situation is different for other primary targets, e.g. mips-elf
and arm-eabi.
Roland McGrath - Oct. 5, 2010, 7:50 p.m.
> Yes, for a Linux target this is what I'd expect: a small handful of
> affected projects.  I'm just asking the community to keep in mind that 
> the situation is different for other primary targets, e.g. mips-elf
> and arm-eabi.

IMHO for any target the build ID feature is also useful (only slightly less
so if there are never core dumps, but still quite useful).  If the ld
orphan placement behavior is less useful than it might be on some targets,
perhaps it can be improved in ld.

Thanks,
Roland
Alexandre Oliva - Oct. 6, 2010, 8:36 a.m.
On Oct  5, 2010, Roland McGrath <roland@redhat.com> wrote:

>> Alex, can this do something bad to bootstrap-debug?  I wonder if having 
>> different -g settings for stage2 and stage3 would cause different build 
>> IDs and ultimately cause a comparison script.

> Different output of any kind (including DWARF and symbol tables) in the
> final linked binaries will produce different build IDs, yes.

As long as the build IDs are in executables, rather than in object
files, we should be fine.  The -checksum object files, used to ensure
compatibility with precompiled headers, will end up different if the
buildids change, because other portions of the binary are different, but
we already disregard differences in the -checksum object files anyway,
and we did even before compare-debug came into the picture.

I wonder if it would make sense to use the compiler's buildid for this
purpose.  Roland, is it possible/easy for a running executable to obtain
its own buildid?
Roland McGrath - Oct. 6, 2010, 5:40 p.m.
> As long as the build IDs are in executables, rather than in object
> files, we should be fine.

Ah, good.

> I wonder if it would make sense to use the compiler's buildid for this
> purpose.  Roland, is it possible/easy for a running executable to obtain
> its own buildid?

It's certainly possible (it's just some of your text) but not inherently
easy.  The .note.gnu.build-id section does not have any automagic symbols
(unless ld does something I don't know about).  So you'd have to use a
linker script to define some, or else examine your own ELF header to find a
PT_NOTE and decode your notes to find it.


Thanks,
Roland

Patch

diff --git a/gcc/configure b/gcc/configure
index e2c0a13..dc3601f 100755  
--- a/gcc/configure
+++ b/gcc/configure
@@ -25104,7 +25104,7 @@  fi
 if test "${enable_linker_build_id+set}" = set; then :
   enableval=$enable_linker_build_id;
 else
-  enable_linker_build_id=no
+  enable_linker_build_id=$gcc_cv_ld_buildid
 fi
 
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 14690d3..dfcac06 100644  
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4115,7 +4115,7 @@  AC_ARG_ENABLE(linker-build-id,
 [  --enable-linker-build-id
                           compiler will always pass --build-id to linker],
 [],
-enable_linker_build_id=no)
+[enable_linker_build_id=$gcc_cv_ld_buildid])
 
 if test x"$enable_linker_build_id" = xyes; then
   if test x"$gcc_cv_ld_buildid" = xyes; then
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index ce6b5cf..ab5bf3b 100644  
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1635,12 +1635,14 @@  building runtime libraries.  @samp{@var{
 list of maps of the form @samp{@var{old}=@var{new}}.
 
 @item --enable-linker-build-id
-Tells GCC to pass @option{--build-id} option to the linker for all final
+@itemx --disable-linker-build-id
+Tells GCC to pass the @option{--build-id} option to the linker for all final
 links (links performed without the @option{-r} or @option{--relocatable}
 option), if the linker supports it.  If you specify
 @option{--enable-linker-build-id}, but your linker does not
-support @option{--build-id} option, a warning is issued and the
-@option{--enable-linker-build-id} option is ignored.  The default is off.
+support the @option{--build-id} option, a warning is issued and the
+@option{--enable-linker-build-id} option is ignored.
+The default is on if the linker supports it.
 
 @item --enable-gnu-unique-object
 @itemx --disable-gnu-unique-object