Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 7/4/2014 12:08 AM, Hans-Peter Nilsson wrote: Currently, c-cppbuiltin.c doesn't provide proper defines for this support. > >We > >currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in > >pa-linux.h. I thought that was cheating! 1/2:) > I'll experiment with defining ATOMIC_INT_LOCK_FREE there. > >It should already be defined, Yes, if the proper insn patterns are in place, those macros are automatically defined. They aren't if library functions are called, regardless of lock-freelessness of those functions. That is the problem. I added the __GCC_HAVE_SYNC_COMPARE_AND_SWAP defines when I saw that the library implementation was being detected by some packages. Trying an even bigger cheat: #define HAVE_sync_compare_and_swapqi 1 #define HAVE_sync_compare_and_swaphi 1 #define HAVE_sync_compare_and_swapsi 1 This seems to give __GCC_ATOMIC_INT_LOCK_FREE = 2, etc. Have to see if this works with our library functions :- Dave -- John David Anglindave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On Tue, 1 Jul 2014, Jonathan Wakely wrote: > On 1 July 2014 20:58, John David Anglin wrote: > > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: > > > >> On 1 July 2014 09:40, Matthias Klose wrote: > >>> > >>> - HPPA (build log [2]), is missing all the future_base symbols and > >>> exception_ptr13exception symbols, current_exception and > >>> rethrow_exception. Apparently the cheat mentioned below didn't fully work. :) > >> This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and > >> exception_ptr implementations rely on usable atomics. > > > > > > ARM and HPPA use kernel assisted libraries for atomic support. Not exactly > > lock free, but possibly good enough... > > > > Currently, c-cppbuiltin.c doesn't provide proper defines for this support. > > We > > currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in > > pa-linux.h. I thought that was cheating! 1/2 :) > I'll experiment with defining ATOMIC_INT_LOCK_FREE there. > > It should already be defined, Yes, if the proper insn patterns are in place, those macros are automatically defined. They aren't if library functions are called, regardless of lock-freelessness of those functions. brgds, H-P
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 01/07/14 09:40, Matthias Klose wrote: on some linux architectures there are some symbols missing in libstdc++.so.6 built from the 4.9 branch. I didn't notice before due to a packaging bug. affected are ARM32, HPPA, SPARC. - ARM32 (build log [1], both soft and hard float) are missing __aeabi_atexit@CXXABI_ARM_1.3.3 __aeabi_vec_* Can these be ignored? __aeabi_atexit is the function to be used instead of __cxa_atexit for the arm-none-linux-gnueabi(hf) targets as well as arm-none-eabi. Grokking around libstdc++-v3 I would have expected config/os/gnu-linux/arm-eabi-extra.ver to have added these symbols in and I'm not sure what's going on here. So prima-facie this is a bug. I wonder if something's broken in the handling of port_specific_symbol_files for arm. regards Ramana - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. - SPARC (build log [3]) configured for sparc64-linux-gnu is missing symbols in the 32bit multilib build, although these are present in a sparc-linux-gnu build. Missing are same ones as in the HPPA build, long double 128 related symbols, numeric_limits, and some math symbols. Looks like more than one issue is involved, I remember that the math symbols were already dropped in earlier versions for other architectures. The build is configured -with-long-double-128. Matthias [1] https://buildd.debian.org/status/fetch.php?pkg=gcc-4.9&arch=armhf&ver=4.9.0-8&stamp=1403809654 [2] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=hppa&ver=4.9.0-9&stamp=1404018503 [3] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sparc64&ver=4.9.0-9&stamp=1404033854
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 01/07/14 20:58, John David Anglin wrote: On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: On 1 July 2014 09:40, Matthias Klose wrote: - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and exception_ptr implementations rely on usable atomics. ARM and HPPA use kernel assisted libraries for atomic support. Not exactly lock free, but possibly good enough... Currently, c-cppbuiltin.c doesn't provide proper defines for this support. We currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. We then need to do the same on ARM especially for older architectures that don't have these sync patterns. Ramana Thanks, Dave -- John David Anglin dave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1-Jul-14, at 4:40 AM, Matthias Klose wrote: Looks like more than one issue is involved, I remember that the math symbols were already dropped in earlier versions for other architectures. The build is configured -with-long-double-128. Long double is 64 bits on hppa-linux. Dave -- John David Anglin dave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On Tue, Jul 01, 2014 at 10:40:06AM +0200, Matthias Klose wrote: > on some linux architectures there are some symbols missing in libstdc++.so.6 > built from the 4.9 branch. I didn't notice before due to a packaging bug. > affected are ARM32, HPPA, SPARC. > > - ARM32 (build log [1], both soft and hard float) are missing > __aeabi_atexit@CXXABI_ARM_1.3.3 > __aeabi_vec_* > >Can these be ignored? > > - HPPA (build log [2]), is missing all the future_base symbols and >exception_ptr13exception symbols, current_exception and >rethrow_exception. > > - SPARC (build log [3]) configured for sparc64-linux-gnu is missing >symbols in the 32bit multilib build, although these are present >in a sparc-linux-gnu build. Missing are same ones as in the HPPA >build, long double 128 related symbols, numeric_limits, and some >math symbols. > >Looks like more than one issue is involved, I remember that the >math symbols were already dropped in earlier versions for other >architectures. The build is configured -with-long-double-128. > I think that for sparc long double issue, the problem is that -with-long-double-128 doesn't work as -mlong-double-64 is forced when -m32 is used. I sent a patch a few months ago [1], but it has some side effect and I never came to a better version. Any help on how to do that properly is welcome, and I can build test some patches if needed. [1] https://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1 July 2014 20:58, John David Anglin wrote: > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: > >> On 1 July 2014 09:40, Matthias Klose wrote: >>> >>> - HPPA (build log [2]), is missing all the future_base symbols and >>> exception_ptr13exception symbols, current_exception and >>> rethrow_exception. >> >> >> This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and >> exception_ptr implementations rely on usable atomics. > > > ARM and HPPA use kernel assisted libraries for atomic support. Not exactly > lock free, but possibly good enough... > > Currently, c-cppbuiltin.c doesn't provide proper defines for this support. > We > currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in > pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. It should already be defined, but its value is what matters for libstdc++'s purposes. To be honest I'm not sure if we really need the value to be greater than one, if it's equal to one that might work. We'd need to check though.
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote: On 1 July 2014 09:40, Matthias Klose wrote: - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and exception_ptr implementations rely on usable atomics. ARM and HPPA use kernel assisted libraries for atomic support. Not exactly lock free, but possibly good enough... Currently, c-cppbuiltin.c doesn't provide proper defines for this support. We currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. Thanks, Dave -- John David Anglin dave.ang...@bell.net
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
Am 01.07.2014 11:32, schrieb Jonathan Wakely: > On 1 July 2014 09:40, Matthias Klose wrote: >> - HPPA (build log [2]), is missing all the future_base symbols and >>exception_ptr13exception symbols, current_exception and >>rethrow_exception. > > This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and > exception_ptr implementations rely on usable atomics. thanks for the reminder. then the same missing symbols for sparc is a missing --with-cpu-32=ultrasparc. Matthias
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
On 1 July 2014 09:40, Matthias Klose wrote: > - HPPA (build log [2]), is missing all the future_base symbols and >exception_ptr13exception symbols, current_exception and >rethrow_exception. This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and exception_ptr implementations rely on usable atomics. I don't know about the other missing symbols.
missing symbols in libstdc++.so.6 built from the 4.9 branch
on some linux architectures there are some symbols missing in libstdc++.so.6 built from the 4.9 branch. I didn't notice before due to a packaging bug. affected are ARM32, HPPA, SPARC. - ARM32 (build log [1], both soft and hard float) are missing __aeabi_atexit@CXXABI_ARM_1.3.3 __aeabi_vec_* Can these be ignored? - HPPA (build log [2]), is missing all the future_base symbols and exception_ptr13exception symbols, current_exception and rethrow_exception. - SPARC (build log [3]) configured for sparc64-linux-gnu is missing symbols in the 32bit multilib build, although these are present in a sparc-linux-gnu build. Missing are same ones as in the HPPA build, long double 128 related symbols, numeric_limits, and some math symbols. Looks like more than one issue is involved, I remember that the math symbols were already dropped in earlier versions for other architectures. The build is configured -with-long-double-128. Matthias [1] https://buildd.debian.org/status/fetch.php?pkg=gcc-4.9&arch=armhf&ver=4.9.0-8&stamp=1403809654 [2] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=hppa&ver=4.9.0-9&stamp=1404018503 [3] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sparc64&ver=4.9.0-9&stamp=1404033854
Re: AIX libstdc++ missing symbols
On 09/24/2011 12:23 AM, David Edelsohn wrote: My latest bootstrap of GCC on AIX failed due to missing symbols in libstdc++ expected by libgmpxx: On x86_64-linux are both still exported. And for sure nobody worked on the code itself. I would say, it's a compiler issue.. Paolo.
AIX libstdc++ missing symbols
My latest bootstrap of GCC on AIX failed due to missing symbols in libstdc++ expected by libgmpxx: exec(): 0509-036 Cannot load program exec(): 0509-036 Cannot load program /tmp/20110922/./gcc/cc1plus/tmp/20110922/./g cc/cc1plus because of the following errors: because of the following errors: 0509-130 Symbol resolution failed for 0509-130 Symbol resolution failed for /usr/gnu/lib/libgmpxx.a(libgmpxx .so.4)/usr/gnu/lib/libgmpxx.a(libgmpxx.so.4) because: because: 0509-136 Symbol 0509-136 Symbol _ZNSt6localeD1Ev_ZNSt6localeD1Ev (number (number 44) is not exporte d from dependent module ) is not exported from dependent module /tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++. so.6)/tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6). . 0509-136 Symbol 0509-136 Symbol _ZNSt6localeC1ERKS__ZNSt6localeC1ERKS_ (number (number 66) is not e xported from dependent module ) is not exported from dependent module /tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++. so.6)/tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6). . 0509-136 Symbol 0509-136 Symbol _ZNSt8ios_base4InitD1Ev_ZNSt8ios_base4InitD1Ev (number (number 1010 ) is not exported from dependent module ) is not exported from dependent module /tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++. so.6)/tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6). . 0509-136 Symbol 0509-136 Symbol _ZNSt8ios_base4InitC1Ev_ZNSt8ios_base4InitC1Ev (number (number ) is not exported from dependent module ) is not exported from dependent module /tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++. so.6)/tmp/20110922/powerpc-ibm-aix5.3.0.0/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6). Any idea what has changed and why those symbols no longer are exported by libstdc++? This seems like a libstdc++ ABI change if they really disappeared. Thanks, David
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On 14/10/2010 19:11, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> The consequence of this is that either there are going to be undefined
>> symbols in the final executable, or the linker has to perform another round
>> of
>> library scanning. It occurred to me that the semantics of this might even
>> not
>> have been decided yet, since ELF platforms are perfectly happy with undefined
>> symbols at final link time.
>
> Only when linking dynamically, though. This suggests that your test
> case should fail on ELF when linking with -static. If not, why not?
>
> Ian
My testcase was pretty much just hello world, and the reason it wouldn't
fail on ELF with -static is because:
> %{fuse-linker-plugin: \
> -plugin %(linker_plugin_file) \
> -plugin-opt=%(lto_wrapper) \
> -plugin-opt=-fresolution=%u.res \
> %{static|static-libgcc:-plugin-opt=-pass-through=%(lto_libgcc)} \
> %{static:-plugin-opt=-pass-through=-lc} \
> } \
... -lc gets added back in right at the very end of the link, thanks to that
pass-through option.
What I'm planning on COFF is to figure a way to add further pass-through
options for all the -l options and .a files in LIB_SPEC.
cheers,
DaveK
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On 14/10/2010 17:12, Dave Korn wrote:
> On 14/10/2010 16:24, Richard Guenther wrote:
>> On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn
>> wrote:
>>> I *think* that re-adding the stdlibs after all
>>> the new input files in the plugin might work, but haven't tried it yet.
It does do the job, and I see there's already a spec to pass through -lc
when static linking. The right solution looks to me like extending the
%{fuse-linker-plugin:} spec on COFF platforms in a way that adds pass-through
options for all the standard libs in LIB_SPEC, and I'll develop a patch along
those lines if you can't see any objection.
cheers,
DaveK
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
Dave Korn writes: > The consequence of this is that either there are going to be undefined > symbols in the final executable, or the linker has to perform another round of > library scanning. It occurred to me that the semantics of this might even not > have been decided yet, since ELF platforms are perfectly happy with undefined > symbols at final link time. Only when linking dynamically, though. This suggests that your test case should fail on ELF when linking with -static. If not, why not? Ian
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On 14/10/2010 16:24, Richard Guenther wrote: > On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn wrote: >> On 14/10/2010 15:44, Richard Guenther wrote: >>> I have no idea about the linker-plugin side, but we could of course >>> avoid generating any calls that were not there before (by for example >>> streaming builtin decls and only if they are used). But that's as much >>> a workaround as fixing things up in the linker afterwards ... >> Sorry, I don't quite understand that suggestion! Do you mean we'd emit a >> symbol for printf and that would result in an explicit printf which wouldn't >> have the chance of being optimised to a puts at link-time? > > Yes. I'd rather leave that as a real last resort! >> If so I see how >> it'd work, but it would be a shame to lose optimisation in LTO. Or to >> include >> unnecessary library members. I *think* that re-adding the stdlibs after all >> the new input files in the plugin might work, but haven't tried it yet. >> >> I have the same problem with '__main', BTW. Is that supposed to count as a >> builtin, or do we need to do something in expand_main_function() to make LTO >> aware when it calls __main? > > Hm, I don't know - I suppose that's from the crt*.o stuff? Typically it's from libgcc: " If no init section is available, when GCC compiles any function called `main' (or more accurately, any function designated as a program entry point by the language front end calling `expand_main_function'), it inserts a procedure call to `__main' as the first executable code after the function prologue. The `__main' function is defined in `libgcc2.c' and runs the global constructors." On cygwin, it's supplied by libc. On other systems I don't know, maybe it can be in the crt.o files, but in that case there wouldn't be any problem with it getting pulled into the link, it's only a problem when it's a library archive member. > The main function itself should already appear in the symbols. It does, but there's no reference to __main. I was wondering if that was supposed to happen, and looking at expand_main_function I guess so, because it's calling "emit_library_call (init_one_libfunc (...))", but this is one libfunc that we know can't be optimised away at linktime, so it would probably be OK to stream it. (But there's a lot I don't know about LTO, so I could always be wrong there.) cheers, DaveK
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn wrote: > On 14/10/2010 15:44, Richard Guenther wrote: >> On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn >> wrote: > >>> Nor indeed is there any sign of puts, which is what the generated ltrans0.s >>> file ends up optimising it to (as indeed does the native code in the >>> original >>> .o file). I'm assuming that this is by design and is for some reason along >>> the lines that we don't even know whether or which function calls are >>> actually >>> going to be emitted until link time? >> >> I think this is because builtin functions are handled specially (their decls >> are not streamed, likewise I think we don't stream their cgraph nodes). > > Ah, yes; -fno-builtin avoids it, for example. > >> As you noted we may eventually fold printf to puts (we may also generate >> a memcpy call out of an aggregate assignment), so it might not make >> your life perfect if we emit symbols for those calls (as indeed we don't know >> which ones we will emit at link time). > > Yes, I can see that we'd quite possibly end up with unused library code > pulled into the link. > >>> It makes life complicated in the linker though, because it means there are >>> symbols present in the object files that the plugin adds via the >>> add_input_files callback that weren't in the original symbols the linker >>> presented via add_symbols when it initially claimed the object file >>> containing >>> the IR. >>> >>> The consequence of this is that either there are going to be undefined >>> symbols in the final executable, or the linker has to perform another round >>> of >>> library scanning. It occurred to me that the semantics of this might even >>> not >>> have been decided yet, since ELF platforms are perfectly happy with >>> undefined >>> symbols at final link time. The only documentation I know of that specifies >>> the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't >>> say >>> anything explicit about this; maybe I've failed to infer something that I >>> should have. >> >> Yeah, I think you have to deal with undefined references to "standard" >> functions (mostly from libc, libm but maybe also from libpthread or so). > > Well, the thing I'm trying to figure out is how to deal with them. COFF > doesn't allow undefined references in executables. > >>> So, is there a defined way in which this is supposed to work? And if the >>> linker is supposed to rescan the libs after the plugin adds files, is it >>> supposed to offer any archive members it finds to the plugin for claiming? >>> Should there be multiple iterations of claiming files and calling >>> all_symbols_read? And if not, what about if the archive members we find on >>> the second pass contain LTO IR? >>> >>> It occurs to me that maybe this is what the add_input_library hook is for: >>> perhaps a simple fix would be for collect2 to pass a list of all the stdlibs >>> to the plugin as a plugin option, and it could add_input_library them after >>> it's finished adding object files. Would that be a reasonable approach? >>> >>> (Right now I have a "working" COFF lto-plugin, but the link fails with >>> unresolved symbols unless I manually add (e.g.) "-Wl,-u,_puts (... etc.)" to >>> the command-line to make sure all the required libc archive members get >>> pulled >>> in during the first pass over libs!) >> >> I have no idea about the linker-plugin side, but we could of course >> avoid generating any calls that were not there before (by for example >> streaming builtin decls and only if they are used). But that's as much >> a workaround as fixing things up in the linker afterwards ... > > Sorry, I don't quite understand that suggestion! Do you mean we'd emit a > symbol for printf and that would result in an explicit printf which wouldn't > have the chance of being optimised to a puts at link-time? Yes. > If so I see how > it'd work, but it would be a shame to lose optimisation in LTO. Or to include > unnecessary library members. I *think* that re-adding the stdlibs after all > the new input files in the plugin might work, but haven't tried it yet. > > I have the same problem with '__main', BTW. Is that supposed to count as a > builtin, or do we need to do something in expand_main_function() to make LTO > aware when it calls __main? Hm, I don't know - I suppose that's from the crt*.o stuff? The main function itself should already appear in the symbols. Richard. > > cheers, > DaveK > > >
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On 14/10/2010 15:44, Richard Guenther wrote: > On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn wrote: >> Nor indeed is there any sign of puts, which is what the generated ltrans0.s >> file ends up optimising it to (as indeed does the native code in the original >> .o file). I'm assuming that this is by design and is for some reason along >> the lines that we don't even know whether or which function calls are >> actually >> going to be emitted until link time? > > I think this is because builtin functions are handled specially (their decls > are not streamed, likewise I think we don't stream their cgraph nodes). Ah, yes; -fno-builtin avoids it, for example. > As you noted we may eventually fold printf to puts (we may also generate > a memcpy call out of an aggregate assignment), so it might not make > your life perfect if we emit symbols for those calls (as indeed we don't know > which ones we will emit at link time). Yes, I can see that we'd quite possibly end up with unused library code pulled into the link. >> It makes life complicated in the linker though, because it means there are >> symbols present in the object files that the plugin adds via the >> add_input_files callback that weren't in the original symbols the linker >> presented via add_symbols when it initially claimed the object file >> containing >> the IR. >> >> The consequence of this is that either there are going to be undefined >> symbols in the final executable, or the linker has to perform another round >> of >> library scanning. It occurred to me that the semantics of this might even >> not >> have been decided yet, since ELF platforms are perfectly happy with undefined >> symbols at final link time. The only documentation I know of that specifies >> the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't >> say >> anything explicit about this; maybe I've failed to infer something that I >> should have. > > Yeah, I think you have to deal with undefined references to "standard" > functions (mostly from libc, libm but maybe also from libpthread or so). Well, the thing I'm trying to figure out is how to deal with them. COFF doesn't allow undefined references in executables. >> So, is there a defined way in which this is supposed to work? And if the >> linker is supposed to rescan the libs after the plugin adds files, is it >> supposed to offer any archive members it finds to the plugin for claiming? >> Should there be multiple iterations of claiming files and calling >> all_symbols_read? And if not, what about if the archive members we find on >> the second pass contain LTO IR? >> >> It occurs to me that maybe this is what the add_input_library hook is for: >> perhaps a simple fix would be for collect2 to pass a list of all the stdlibs >> to the plugin as a plugin option, and it could add_input_library them after >> it's finished adding object files. Would that be a reasonable approach? >> >> (Right now I have a "working" COFF lto-plugin, but the link fails with >> unresolved symbols unless I manually add (e.g.) "-Wl,-u,_puts (... etc.)" to >> the command-line to make sure all the required libc archive members get >> pulled >> in during the first pass over libs!) > > I have no idea about the linker-plugin side, but we could of course > avoid generating any calls that were not there before (by for example > streaming builtin decls and only if they are used). But that's as much > a workaround as fixing things up in the linker afterwards ... Sorry, I don't quite understand that suggestion! Do you mean we'd emit a symbol for printf and that would result in an explicit printf which wouldn't have the chance of being optimised to a puts at link-time? If so I see how it'd work, but it would be a shame to lose optimisation in LTO. Or to include unnecessary library members. I *think* that re-adding the stdlibs after all the new input files in the plugin might work, but haven't tried it yet. I have the same problem with '__main', BTW. Is that supposed to count as a builtin, or do we need to do something in expand_main_function() to make LTO aware when it calls __main? cheers, DaveK
Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
On Thu, Oct 14, 2010 at 4:59 PM, Dave Korn wrote:
>
> Hello list,
>
> When I compile this source with -flto:
>
>> extern int retval;
>> int func (void)
>> {
>> return retval;
>> }
>
> ... the LTO symbol table contains both symbols:
>
>> /gnu/binutils/git.repo/obj/ld/test/func.o: file format pe-i386
>>
>> Contents of section .gnu.lto_.symtab.227b80e3:
>> 66756e63 func
>> 0010 4b00 72657476 616c 0200 K...retval..
>> 0020 5100 ..Q...
>
> But when I compile this:
>
>> extern int printf (const char *fmt, ...);
>>
>> extern const char *text;
>> extern int func (void);
>>
>> int retval = 0;
>>
>> int main (int argc, const char **argv)
>> {
>> printf ("%s\n", text);
>> return func ();
>> }
>
> ... there is no sign of printf:
>
>> /gnu/binutils/git.repo/obj/ld/test/main.o: file format pe-i386
>>
>> Contents of section .gnu.lto_.symtab.6e8eaf64:
>> 6d61696e main
>> 0010 4b00 66756e63 0200 K...func
>> 0020 5b00 74657874 0200 [...text
>> 0030 5f00 72657476 _...retv
>> 0040 616c 6100 ala.
>> 0050 ..
>
> Nor indeed is there any sign of puts, which is what the generated ltrans0.s
> file ends up optimising it to (as indeed does the native code in the original
> .o file). I'm assuming that this is by design and is for some reason along
> the lines that we don't even know whether or which function calls are actually
> going to be emitted until link time?
I think this is because builtin functions are handled specially (their decls
are not streamed, likewise I think we don't stream their cgraph nodes).
As you noted we may eventually fold printf to puts (we may also generate
a memcpy call out of an aggregate assignment), so it might not make
your life perfect if we emit symbols for those calls (as indeed we don't know
which ones we will emit at link time).
> It makes life complicated in the linker though, because it means there are
> symbols present in the object files that the plugin adds via the
> add_input_files callback that weren't in the original symbols the linker
> presented via add_symbols when it initially claimed the object file containing
> the IR.
>
> The consequence of this is that either there are going to be undefined
> symbols in the final executable, or the linker has to perform another round of
> library scanning. It occurred to me that the semantics of this might even not
> have been decided yet, since ELF platforms are perfectly happy with undefined
> symbols at final link time. The only documentation I know of that specifies
> the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't say
> anything explicit about this; maybe I've failed to infer something that I
> should have.
Yeah, I think you have to deal with undefined references to "standard"
functions (mostly from libc, libm but maybe also from libpthread or so).
> So, is there a defined way in which this is supposed to work? And if the
> linker is supposed to rescan the libs after the plugin adds files, is it
> supposed to offer any archive members it finds to the plugin for claiming?
> Should there be multiple iterations of claiming files and calling
> all_symbols_read? And if not, what about if the archive members we find on
> the second pass contain LTO IR?
>
> It occurs to me that maybe this is what the add_input_library hook is for:
> perhaps a simple fix would be for collect2 to pass a list of all the stdlibs
> to the plugin as a plugin option, and it could add_input_library them after
> it's finished adding object files. Would that be a reasonable approach?
>
> (Right now I have a "working" COFF lto-plugin, but the link fails with
> unresolved symbols unless I manually add (e.g.) "-Wl,-u,_puts (... etc.)" to
> the command-line to make sure all the required libc archive members get pulled
> in during the first pass over libs!)
I have no idea about the linker-plugin side, but we could of course
avoid generating any calls that were not there before (by for example
streaming builtin decls and only if they are used). But that's as much
a workaround as fixing things up in the linker afterwards ...
Richard.
> cheers,
> DaveK
> --
> (*) - http://gcc.gnu.org/wiki/whopr/driver
>
>
LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF
Hello list,
When I compile this source with -flto:
> extern int retval;
> int func (void)
> {
> return retval;
> }
... the LTO symbol table contains both symbols:
> /gnu/binutils/git.repo/obj/ld/test/func.o: file format pe-i386
>
> Contents of section .gnu.lto_.symtab.227b80e3:
> 66756e63 func
> 0010 4b00 72657476 616c 0200 K...retval..
> 0020 5100 ..Q...
But when I compile this:
> extern int printf (const char *fmt, ...);
>
> extern const char *text;
> extern int func (void);
>
> int retval = 0;
>
> int main (int argc, const char **argv)
> {
> printf ("%s\n", text);
> return func ();
> }
... there is no sign of printf:
> /gnu/binutils/git.repo/obj/ld/test/main.o: file format pe-i386
>
> Contents of section .gnu.lto_.symtab.6e8eaf64:
> 6d61696e main
> 0010 4b00 66756e63 0200 K...func
> 0020 5b00 74657874 0200 [...text
> 0030 5f00 72657476 _...retv
> 0040 616c 6100 ala.
> 0050 ..
Nor indeed is there any sign of puts, which is what the generated ltrans0.s
file ends up optimising it to (as indeed does the native code in the original
.o file). I'm assuming that this is by design and is for some reason along
the lines that we don't even know whether or which function calls are actually
going to be emitted until link time?
It makes life complicated in the linker though, because it means there are
symbols present in the object files that the plugin adds via the
add_input_files callback that weren't in the original symbols the linker
presented via add_symbols when it initially claimed the object file containing
the IR.
The consequence of this is that either there are going to be undefined
symbols in the final executable, or the linker has to perform another round of
library scanning. It occurred to me that the semantics of this might even not
have been decided yet, since ELF platforms are perfectly happy with undefined
symbols at final link time. The only documentation I know of that specifies
the linker plugin API is the GCC wiki whopr/driver page(*), and it doesn't say
anything explicit about this; maybe I've failed to infer something that I
should have.
So, is there a defined way in which this is supposed to work? And if the
linker is supposed to rescan the libs after the plugin adds files, is it
supposed to offer any archive members it finds to the plugin for claiming?
Should there be multiple iterations of claiming files and calling
all_symbols_read? And if not, what about if the archive members we find on
the second pass contain LTO IR?
It occurs to me that maybe this is what the add_input_library hook is for:
perhaps a simple fix would be for collect2 to pass a list of all the stdlibs
to the plugin as a plugin option, and it could add_input_library them after
it's finished adding object files. Would that be a reasonable approach?
(Right now I have a "working" COFF lto-plugin, but the link fails with
unresolved symbols unless I manually add (e.g.) "-Wl,-u,_puts (... etc.)" to
the command-line to make sure all the required libc archive members get pulled
in during the first pass over libs!)
cheers,
DaveK
--
(*) - http://gcc.gnu.org/wiki/whopr/driver
Re: missing symbols
On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote: On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote: > In the following code, compiled with > g++ cls.cc -Wall -W -g3 -o cls > > why only only virtual functions f1, f2 and constructor is listed by nm. Because they are needed for the vtable. While f3 is declared as inline and not used so it is not outputed. Wierd assembler file, generated by "-S" parameter, include all information about test class methods: test,f1,f2,f3 Not really because that is what you get with -g3. Thanks, Andrew Pinski
Re: missing symbols
On 6/18/07, costin_c <[EMAIL PROTECTED]> wrote:
In the following code, compiled with
g++ cls.cc -Wall -W -g3 -o cls
why only only virtual functions f1, f2 and constructor is listed by nm.
Only debugging symbols for virtual functions are included in
executable output file ?
//cls.cc
#include
using namespace std;
class test
{
public:
int u;
test(int t){u=t;};
virtual void f1(){
cout <
Wierd assembler file, generated by "-S" parameter, include all
information about test class methods: test,f1,f2,f3
..
.string "test::test"
.long 0x5d40
.string "test::f2"
.long 0x5d70
.string "test::f3"
.long 0x5e4d
.string "test::f1"
.long 0x5e71
.string "main"
missing symbols
In the following code, compiled with
g++ cls.cc -Wall -W -g3 -o cls
why only only virtual functions f1, f2 and constructor is listed by nm.
Only debugging symbols for virtual functions are included in
executable output file ?
//cls.cc
#include
using namespace std;
class test
{
public:
int u;
test(int t){u=t;};
virtual void f1(){
cout <
