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: "Maciej W. Rozycki" <macro at mips dot com>
- To: Djordje Todorovic <djordje dot todorovic at rt-rk dot com>, Pedro Alves <palves at redhat 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: Wed, 25 Oct 2017 23:38:23 +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
- 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>
Hi Djordje (and Pedro, see below),
> Please notice that I have reformatted patches 1/3 and 3/3, according
> your comments, and also tweaked a little bit patch 3/3.
Thank you. There's still a small nit remaining WRT 1/3, but as I have
noted in a separate reply I'll handle it myself when committing.
> Regarding patch 3/3, as Pedro said, currently “thread” function has a
> piece of code that is never going to be executed since core file is
> going to be generated as soon as the first thread reaches the thread
> function. So, since we are testing fetching value of TLS variable from
> core file, creating just a one thread in test case would be enough and
> regarding that, I have cut unnecessary code from the function.
Hmm, to understand how exactly the bug triggers (as you may recall long
ago I observed GDB prefers LWPID over PID if available) I ran your test
case with the code changes removed and the test has still passed across
the three ABIs. So it does not actually cover the case concerned here.
I still would like to keep it to verify the consistency between core files
written and read (following the various issues discovered in the course of
this review, including the n32 BFD fix I have cc-ed you on lately),
however that brings the question again about how you originally observed
the problem you've addressed. Is there another test scenario that can be
created?
Also now that the issue of using `run' has been resolved, I have verified
the test case with a cross-debugger against a remote target and the result
is a FAIL like below:
(gdb) file .../gdb/testsuite/outputs/gdb.threads/tls-core/tls-core
Reading symbols from .../gdb/testsuite/outputs/gdb.threads/tls-core/tls-core...done.
(gdb) core .../gdb/testsuite/outputs/gdb.threads/tls-core/gcore.test
warning: core file may not match specified executable file.
[New LWP 8829]
[New LWP 8828]
Core was generated by `.../gdb/testsuite/output'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 thread_proc (arg=0x0) at .../gdb/testsuite/gdb.threads/tls-core.c:25
25 return arg;
[Current thread is 1 (LWP 8829)]
(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'.
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?
Maciej