From: Steve Ellcey <sellcey@cavium.com>
To: Pedro Alves <palves@redhat.com>, gdb@sourceware.org
Subject: Re: gdb / thread_db / multiple ABI question
Date: Mon, 10 Jul 2017 21:22:00 -0000 [thread overview]
Message-ID: <1499721728.13519.58.camel@cavium.com> (raw)
In-Reply-To: <a05b8a10-b93e-80a6-a4e1-60f72a0afcd0@redhat.com>
On Mon, 2017-07-10 at 19:21 +0100, Pedro Alves wrote:
> On 07/10/2017 07:02 PM, Steve Ellcey wrote:
> >
> > No, without thread_db I get this:
> >
> > (gdb) file m32
> > Reading symbols from m32...done.
> > (gdb) core c_32
> > [New LWP 79425]
> > [New LWP 79425]
> > [New LWP 79425]
> This means that GDB/bfd thinks that there are 3 threads
> in the core, but they all have the same TID, which is of course
> bogus.  So this still looks to me like something is wrong on
> the bfd side.  Try "objdump -h c_32".  You should see
> one ".reg/NNN" section per thread, like e.g.:
FYI: I think I found the cause of this problem.  In bfd/elfxx-
aarch64.c:_bfd_aarch64_elf_grok_prstatus there is code to
differentiate LP64 and ILP32 based on the different sizes of
elf_prstatus (note->descsz). Â But after that differentiation I was
using 12 as the offset of pr_cursig in elf_prstatus and 32 for the
offset of pr_reg in both the ILP32 and LP64 cases. Â I think the offset
of 12 for pr_cursig is OK because there are 3 int fields in front of
it and those are 4 bytes in both modes. Â But the offset of pr_reg
should be 32 for LP64 and 24 for ILP32 because there are two long
variables between pr_cursig and pr_pid so the offset to pr_pid will
differ based on the ABI. Â After this change:
(gdb) file m32
Reading symbols from m32...done.
(gdb) core c_32
[New LWP 15129]
[New LWP 15130]
[New LWP 15128]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/home/sellcey/gdb-ilp32/install/lib64/libthread_db.so.1".
Core was generated by `./m32'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0Â Â 0x00400680 in doSomeThing ()
[Current thread is 1 (Thread 0xf725f490 (LWP 15129))]
(gdb) info threads
 Id   Target Id         FrameÂ
* 1Â Â Â Â Thread 0xf725f490 (LWP 15129) 0x00400680 in doSomeThing ()
 2    Thread 0xf6a5f490 (LWP 15130) 0xf72fa2d0 in __GI___nanosleep (
    requested_time=requested_time@entry=0xf6a5eeb8,Â
    remaining=remaining@entry=0xf6a5eeb8)
    at ../sysdeps/unix/sysv/linux/nanosleep.c:27
 3    Thread 0xf743ef70 (LWP 15128) 0xf72fa2d0 in __GI___nanosleep (
    requested_time=requested_time@entry=0xffa1b1c8,Â
    remaining=remaining@entry=0xffa1b1c8)
    at ../sysdeps/unix/sysv/linux/nanosleep.c:27
prev parent reply other threads:[~2017-07-10 21:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 18:20 Steve Ellcey
2017-07-07 18:36 ` Pedro Alves
2017-07-07 20:30 ` Steve Ellcey
2017-07-10 7:39 ` Yao Qi
2017-07-10 16:58 ` Steve Ellcey
2017-07-10 8:29 ` Andreas Schwab
2017-07-10 9:43 ` Pedro Alves
2017-07-10 18:02 ` Steve Ellcey
2017-07-10 18:21 ` Pedro Alves
2017-07-10 19:45 ` Steve Ellcey
2017-07-11 8:38 ` Yao Qi
2017-07-10 21:22 ` Steve Ellcey [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1499721728.13519.58.camel@cavium.com \
--to=sellcey@cavium.com \
--cc=gdb@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox