Re: [PATCH 0/3] Fix issues with writing Linux core PRSTATUS note on MIPS o32, n32 and n64 into core file

Maciej W. Rozycki
2017-10-25T22:40:38Z

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