[Bug lto/46502] New: collect2 LTO marker detection is fragile wrt. to nm output format

[Bug lto/46502] New: collect2 LTO marker detection is fragile wrt. to nm output format

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46502

           Summary: collect2 LTO marker detection is fragile wrt. to nm
                    output format
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org


When investigating why some users of GCC mainline on Solaris 2 saw more
LTO-related testsuite failures than I, it turned out that collect2 calls some
version of nm to search the object's symbol tables for __gnu_lto_v1.
Unfortunately, this relies on the output format produced by GNU nm -n, and
silently fails if the format is different (i.e. the LTO markers aren't found
and lto1 isn't called).  I noticed this change between Solaris 10 (where I had
no instance of GNU nm in PATH, neither as nm nor as gnm) and Solaris 11 (where
there's /usr/bin/gnm in the default PATH).

This is very fragile, hard to find, and the requirement isn't even documented.

[Bug lto/46502] collect2 LTO marker detection is fragile wrt. to nm output format

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46502

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-17 11:41:11 UTC ---
The marker should be removed.

[Bug lto/46502] collect2 LTO marker detection is fragile wrt. to nm output format

[gseanmcg at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46502

--- Comment #2 from Sean McGovern <gseanmcg at gmail dot com> 2011-11-25 16:32:47 UTC ---
(In reply to comment #0)
> When investigating why some users of GCC mainline on Solaris 2 saw more
> LTO-related testsuite failures than I, it turned out that collect2 calls some
> version of nm to search the object's symbol tables for __gnu_lto_v1.
> Unfortunately, this relies on the output format produced by GNU nm -n, and
> silently fails if the format is different (i.e. the LTO markers aren't found
> and lto1 isn't called).  I noticed this change between Solaris 10 (where I had
> no instance of GNU nm in PATH, neither as nm nor as gnm) and Solaris 11 (where
> there's /usr/bin/gnm in the default PATH).
> This is very fragile, hard to find, and the requirement isn't even documented.

Hi Rainer,

Has this been handled yet?

[Bug lto/46502] collect2 LTO marker detection is fragile wrt. to nm output format

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46502

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-05-07
     Ever Confirmed|0                           |1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-07 11:57:34 UTC ---
Confirmed.  This issue is still present - even the LTO linker plugin identifies
files via that mechanism :/

Looks like simple things "stick" ...

libiberties simple-object could be used to instead query for a
.gnu.lto_.opts section.

The collect2 issue might eventually be "fixed" by making LTO require using
the linker-plugin path.

[Bug lto/46502] collect2 LTO marker detection is fragile wrt. to nm output format

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46502

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.0
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed since GCC 9 and r9-5042.

As for binutils/plugin, https://sourceware.org/bugzilla/show_bug.cgi?id=24768 .

So closing this as fixed.