Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

On 1/7/20 10:40 PM, Nick Bowler wrote:
> On 1/7/20, Bob Friesenhahn <[email protected]> wrote:
>> On Tue, 7 Jan 2020, Nick Bowler wrote:
>>
>>> On 1/7/20, Martin Liška <[email protected]> wrote:
>>>> nm -B detection fails to be detected with -flto and -fno-common CFLAGS:
>>
>> I don't know what vintage this documentation is (the copyright says it
>> is from 2020 so it seems to be the latest), but the page at
>> https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html says this
>> about "-fcommon"
>>
>> "The default is -fno-common, which specifies..."
>>
>> GCC 9.2 documentation says that the default is target dependent, which
>> suggests that some targets use no-common by default.
> 
> I think the fact that this test produces a common symbol most of the
> time, and that nm happens to work under LTO in this specific case, is
> mostly just a happy accident.

Well, the nm is using LTO plugin, so it should properly communicate
symbol types (in ideal world) :)

> 
>>> I'm not 100% sure which libtool features will be affected by this
>>> configuration failure.  It doesn't fatally stop the configure script.
>>> Probably dlpreopen won't work at all?
>>
>> Are there many users of dlpreopen()?
> 
> I imagine there are users of -dlopen, which is supposed to automatically
> fall back to dlpreopen when shared library support is not available (for
> example, if the user configures the package with --disable-shared).
> 
> Whether or not developers routinely test that their packages work with
> shared libraries disabled is another matter.
> 
> Regardless, $global_symbol_pipe is part of the documented libtool
> interface, which says you can do:
> 
>    eval "$NM progname | $global_symbol_pipe"
> 
> This is obviously busted because the failed configure test leads to
> global_symbol_pipe='' which will obviously cause problems in this
> usage (I just tested one of my scripts and yup, it is busted).

Yes, that's what I see for many package failures in openSUSE when I enable
-fno-common in optimization flags:

> 
> But more importantly I suspect the actual busted feature is
> $global_symbol_to_cdecl, which is supposed to produce declarations for
> the symbols you get from global_symbol_pipe.  This is clearly not
> working under LTO as it fails to distinguish functions and variables.
> 
> It might be possible to detect this case in configure and come up with
> a symbol declaration that works for both functions and data, which might
> enable global_symbol_to_cdecl to generate working declarations, and would
> probably fix this configure test and typical usage scenarios like
> dlpreopen.
> 
>>> It's also unfortunate that since there is no way to directly reference
>>> symbol values in standard C, a common way to do so is with dummy array
>>> or function declarations, and lo and behold LTO apparently breaks this
>>> too...
>>
>> LTO often causes strange issues.  It needs to be used with care.
>>
>> Thus far I have seen LTO reduce the output executable size (sometimes
>> substantially if there is a lot of "dead" code) but I have not seen a
>> speed benefit to properly written code.
> 
> When I last played around with LTO on my C code I was hoping to
> achieve reduced executable size but I found the results to be almost
> exactly the same as what I was already getting by compiling everything
> with -ffunction-sections -fdata-sections and then linking with
> -Wl,--gc-sections.  And unlike LTO, those options don't break nm
> which would have required a massive amount of futzing with the
> build system to get things to even work.

I can provide quite some interesting numbers about usage of LTO (ideally with PGO):
http://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html

Or if you want to compare SPEC numbers:
https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch

In both scenarios LTO brings both speed up and size reduction.
And note that we enabled LTO in openSUSE Tumbleweed by default.

Martin

> 
> Cheers,
>    Nick
>