Re: ld-linux-x86-64 core file SIGSEGV

[Florian Weimer <fweimer@redhat.com>]

* Jonny Grant:

> On 22/08/2022 11:43, Florian Weimer wrote:
>> * Jonny Grant:
>> 
>>> I got it to load the debug symbol using "file" command you
>>> mentioned. Unfortunately backtrace still empty.  The debug symbols
>>> /usr/lib/debug/.build-id/61/ef896a699bb1c2e4e231642b2e1688b2f1a61e.debug
>>> are only 592,952 bytes
>>>
>>> I would probably just prefer if binaries weren't separated from their
>>> debug symbols. Do you know any distributions that don't strip symbols
>>> from glibc?
>> 
>> I'm not sure if this is caused by debuginfo separation.  I run into GDB
>> when I use my own custom-built glibc with unstripped debuginfo.
>> 
>> Anyway, you can probably use eu-unstrip from elfutils to undo the
>> debuginfo separation.
>> 
>> Thanks,
>> Florian
>
> That's a good tip than you.
>
> I did use objdump -d on the ld.so, but couldn't spot anything similar
> to what I saw in "layout asm" from gdb.

In my experience, the missing symbols are usually from the main program,
and then the stack backtrace runs off the rails pretty quickly
(resulting in garbage addresses).

> Is it ever possible to match up disassembly with the gdb core
> disassembly this way?

You cloud get the object addresses from /proc/PID/mem, compute the
relative offset, and then use addr2line or objdump to find out more.

Thanks,
Florian