This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file
- From: Pedro Alves <palves at redhat dot com>
- To: "Maciej W. Rozycki" <macro at mips dot com>, Djordje Todorovic <djordje dot todorovic at rt-rk dot com>
- Cc: binutils at sourceware dot org, gdb-patches at sourceware dot org, "nemanja dot popov at rt-rk dot com" <nemanja dot popov at rt-rk dot com>, petar dot jovanovic at rt-rk dot com, "Ananthakrishna Sowda (asowda)" <asowda at cisco dot com>, Nikola Prica <nikola dot prica at rt-rk dot com>
- Date: Fri, 27 Oct 2017 16:00:15 +0100
- Subject: Re: [PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D14B85F73C
- References: <74618d56-fa31-4cfe-329f-6a9078bac92b@rt-rk.com> <alpine.DEB.2.00.1710171449200.3886@tp.orcam.me.uk> <724f0bc9-6744-a915-d19d-77db7e9ce514@rt-rk.com> <alpine.DEB.2.00.1710252126220.3886@tp.orcam.me.uk>
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