[PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file
Pedro Alves
palves@redhat.com
Fri Oct 27 15:00:00 GMT 2017
On 10/25/2017 11:38 PM, Maciej W. Rozycki wrote:
> (gdb) PASS: gdb.threads/tls-core.exp: load generated corefile
> p/x foo
> Cannot find thread-local storage for LWP 8829, executable file .../gdb/testsuite/outputs/gdb.threads/tls-core/tls-core:
> Cannot find thread-local variables on this target
> (gdb) FAIL: gdb.threads/tls-core.exp: print thread-local storage variable
>
> which I am fairly sure that is related (along with the "core file may not
> match specified executable file." message) to an attempt to use native
> `libthread_db'.
The "core file may not match specified executable file." sounds like
something else. I think you'll get that if the program name recorded
in the core data structure is not the same as the name of the executable.
Try setting a breakpoint on core_file_matches_executable_p.
>
> Pedro, do I remember correctly it was you who recently mentioned (maybe
> at the Cauldron) the need to have the issue of using `libthread_db' in
> cross-debugging correctly addressed? For the time being I think we want
> to KFAIL this test case if [is_remote target] (in its recently cleaned-up
> meaning, as the test case actually succeeds with `native-gdbserver') --
> but do we have a tracking bug already?
Right, libthread_db is loaded by the host gdb, and that libthread_db
is only good for native debugging. Things work with live cross-debugging
against gdbserver because in that case it's gdbserver that loads
the right libthread_db, not gdb.
Thanks,
Pedro Alves
More information about the Binutils
mailing list