Bug 46502 - collect2 LTO marker detection is fragile wrt. to nm output format
Summary: collect2 LTO marker detection is fragile wrt. to nm output format
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 9.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks: 46503
  Show dependency treegraph
 
Reported: 2010-11-16 16:32 UTC by Rainer Orth
Modified: 2021-08-25 23:42 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-05-07 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Orth 2010-11-16 16:32:39 UTC
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.
Comment 1 Richard Biener 2010-11-17 11:41:11 UTC
The marker should be removed.
Comment 2 Sean McGovern 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?
Comment 3 Richard Biener 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.
Comment 4 Andrew Pinski 2021-08-25 23:42:51 UTC
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.