| Message ID | 20101005050958.3841D401B2@magilla.sf.frob.com |
|---|---|
| State | New |
| Headers | show |
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.
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
> 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
> 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
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.
> 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
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?
> 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
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