From: Gary Benson <gbenson@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Richard Henderson <rth@redhat.com>, GDB <gdb@sourceware.org>
Subject: Re: Changes required for x86 address spaces
Date: Wed, 21 Oct 2015 08:16:00 -0000 [thread overview]
Message-ID: <20151021081610.GA13381@blade.nx> (raw)
In-Reply-To: <CAMe9rOoOR5qC_r3DKk+_NX_dLm33iWHQ4MSgoAYsAtrkOHp5hA@mail.gmail.com>
H.J. Lu wrote:
> On Tue, Oct 20, 2015 at 3:25 PM, Richard Henderson <rth@redhat.com> wrote:
> > Here are some notes regarding gdb changes required in order to support
> >
> > https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01972.html
> >
> > In my opinion, DW_AT_address_class is best when the alternate
> > address space is truely disjoint, or has a different pointer
> > width. That certainly matches up with the language in the dwarf4
> > doc, and existing usage in the embedded targets.
> >
> > Thus I've arranged for these x86 address spaces to use
> > DW_AT_segment, a dwarf location containing an offset from the flat
> > address space. For the purposes of the debug info, I map
> > __seg_tls to __seg_fs or __seg_gs.
> >
> > The x86-64 abi already has dwarf register numbers allocated for
> > fs_base and gs_base. Thus the location is simply the trivial
> > DW_OP_regx 58 or 59 respectively. The i386 abi does not yet have
> > the same register number pre-allocated; the latest version I see
> > in HJL's github document has dwarf registers 58-59 within a block
> > of reserved values, so for now I'm using the same values for both
> > x86-64 and i386.
>
> Table 2.14: DWARF Register Number Mapping in Intel386 psABI:
>
> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>
> defines
>
> Segment Register ES 40 %es
> Segment Register CS 41 %cs
> Segment Register SS 42 %ss
> Segment Register DS 43 %ds
> Segment Register FS 44 %fs
> Segment Register GS 45 %gs
>
> Why not use them?
x86 has %fs and %fs_base, and %gs and %gs_base. I don't understand
the difference but I do know that when libthread_db asks GDB to look
in FS or GS (in ps_get_thread_area) what GDB actually returns is the
contents of FS_BASE or GS_BASE.
(If GDB could directly access FS_BASE and GS_BASE through regcache or
whatever then thread debugging could be done without the ptrace hacks
in ps_get_thread_area (so presumably faster) but I don't know how to
add this support so I haven't done it.)
Cheers,
Gary
--
http://gbenson.net/
next prev parent reply other threads:[~2015-10-21 8:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-20 22:25 Richard Henderson
2015-10-21 2:38 ` H.J. Lu
2015-10-21 8:16 ` Gary Benson [this message]
2015-10-21 17:47 ` Richard Henderson
2015-10-21 18:36 ` Pedro Alves
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=20151021081610.GA13381@blade.nx \
--to=gbenson@redhat.com \
--cc=gdb@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=rth@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