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

["Maciej W. Rozycki" <macro@mips.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