Changes required for x86 address spaces

[Gary Benson]

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/