https://sourceware.org/bugzilla/show_bug.cgi?id=31895
--- Comment #3 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Corentin Silva Pereira from comment #2)
< Just so you can have more context, our software is developped with QT C++,
> and we have a lot of .o and .so files to link with the main software of our
> solution. One command can link like a 100 files/lib. This is the one that's
> causing this crash.
Just a thought - could your machine be running out of memory ? Given that
the build is so big, maybe there is a memory allocation in the linker
somewhere that is failing (and not being caught) which then goes on to
cause the problems you are seeing.
> Unfortunately, i can't give you the ld command i use because the code
> belongs to my company and i'm not authorized to give it.
That is a shame, but I understand.
> Although i tried to
> compile binutils 2.34 manually and i managed to cause the segfault within
> GDB.
>
> Here's what i got :
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000555555600b03 in elf_link_add_object_symbols (info=<optimized out>,
> abfd=<optimized out>) at elflink.c:5262
> 5262 non_ir_ref_dynamic = h->root.non_ir_ref_dynamic;
Interesting. The 'h' pointer should be valid as the code just before it is:
for (p = htab->root.table.table[i]; p != NULL; p = p->next)
{
h = (struct elf_link_hash_entry *) p;
But the code that follows does this:
if (h->root.type == bfd_link_hash_warning)
h = (struct elf_link_hash_entry *) h->root.u.i.link;
So maybe the problem is that this reassignment of 'h' results in a NUL
pointer.
I suspect however that GDB is mistaken about the line where the fault
is really happening...
> I tried to give -g -O0 to all binutils so i can have all the symbols, but i
> still can't print h or print h->root within GDB.
If you are able to build and run your own linker then you can easily insert
some fprintf() statements of your own in order to help find out what is going
on. (I do this all the time. GDB is great, but sometimes a good old fprintf
is what you need).
> > The 2.34 release of the binutils is quite old now. Are you able to update
> > to a newer version ?
> To answer your question, we are porting the software to Ubuntu 24.04 which
> uses a more recent version of binutils but i still have the problem on
> Ubuntu 24.04 so i don't think it is very related to the version.
You could always try downloading the latest binutils release and building it
for yourself.
I am not sure if looking for a solution this way will help though. Are you
required to use the system supplied version of the binutils when building your
project ? If so, then even if we can say, "oh yes this is a known bug, fixed
in version 2.XX" it will not help. Mind you, if you do have to use the system
supplied version of the binutils then you should really be contacting the
Ubuntu people and asking them for help. After all they are the ones that will
have to patch the linker, once the problem is found.
> Are there elements i can add to the binutils compiling arguments to give you
> more information ? For example, something to generate a coredump or
> something to read those optimized out values
Using fprintf()s is my best suggestion.
You might also find it worthwhile to experiment with using a different linker.
eg GOLD or LLD. It won't solve the BFD linker problem, but it will allow you
to get on with your own development work.
Trying to create a small test case that demonstrates the problem would be
helpful too - assuming that the code does not contain any code that your
employers do not wish to be made public.
Long term - you might want to consider breaking up the application into
smaller components. (If that is possible). Building and linking large
applications always takes a long time, and if you are able to instead just
build small components that then work together, you should find that
development time improves.
--
You are receiving this mail because:
You are on the CC list for the bug.
