[RFA] i386 segment base support

[RFA] i386 segment base support

[Hui Zhu]

Hi guys,

I update the old patch that I post to support segment base value.

Now, it will not show when info reg.
For example:
(gdb) info reg
eax            0x1	1
ecx            0xbffff510	-1073744624
edx            0xbffff530	-1073744592
ebx            0xb7fb5ff4	-1208262668
esp            0xbffff4a0	0xbffff4a0
ebp            0xbffff4f8	0xbffff4f8
esi            0xb7ffece0	-1207964448
edi            0x0	0
eip            0x8048388	0x8048388 <main+20>
eflags         0x286	[ PF SF IF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51
(gdb) info reg cs_base
cs_base        0x0	0
(gdb) info reg gs_base
gs_base        0xb7e6a6b0	-1209620816

Please help me review it.

Thanks,
Hui

2010-05-20  Hui Zhu  <teawater@gmail.com>

	* features/i386/32bit-linux.xml (org.gnu.gdb.i386.linux): Add
	cs_base, ss_base, ds_base, es_base, fs_base and gs_base.

	* amd64-linux-nat.c (user-regs.h): New include.
	(GDT_ENTRY_TLS_MIN, GDT_ENTRY_TLS_MAX): New marco.
	(ps_get_thread_area): New extern.
	(amd64_linux_fetch_inferior_registers): Add
	code to get 32 bits segment registers base.

	* i386-linux-nat.c (user-regs.h): New include.
	(GDT_ENTRY_TLS_ENTRIES, GDT_ENTRY_TLS_MIN,
	GDT_ENTRY_TLS_MAX): New marco.
	(ps_get_thread_area): New extern.
	(i386_linux_fetch_inferior_registers): Add
	code to get segment registers base.

	* i386-linux-tdep.c (user-regs.h): New include.
	(i386_linux_register_reggroup_p): Add check for segment base
	registers.

---
 amd64-linux-nat.c             |   40 ++++++++++++++++++++++++++++++++++++++++
 features/i386/32bit-linux.xml |    6 ++++++
 features/i386/i386-linux.c    |    6 ++++++
 i386-linux-nat.c              |   40 ++++++++++++++++++++++++++++++++++++++++
 i386-linux-tdep.c             |    8 ++++++++
 5 files changed, 100 insertions(+)

--- a/amd64-linux-nat.c
+++ b/amd64-linux-nat.c
@@ -26,6 +26,7 @@
 #include "regset.h"
 #include "linux-nat.h"
 #include "amd64-linux-tdep.h"
+#include "user-regs.h"

 #include "gdb_assert.h"
 #include "gdb_string.h"
@@ -146,12 +147,19 @@ fill_fpregset (const struct regcache *re
    this for all registers (including the floating point and SSE
    registers).  */

+#define GDT_ENTRY_TLS_MIN 12
+#define GDT_ENTRY_TLS_MAX 14
+
+extern ps_err_e ps_get_thread_area (const struct ps_prochandle *ph,
+		                    lwpid_t lwpid, int idx, void **base);
+
 static void
 amd64_linux_fetch_inferior_registers (struct target_ops *ops,
 				      struct regcache *regcache, int regnum)
 {
   struct gdbarch *gdbarch = get_regcache_arch (regcache);
   int tid;
+  int cs_base;

   /* GNU/Linux LWP ID's are process ID's.  */
   tid = TIDGET (inferior_ptid);
@@ -195,6 +203,38 @@ amd64_linux_fetch_inferior_registers (st
 	  amd64_supply_fxsave (regcache, -1, &fpregs);
 	}
     }
+
+  /* Get the base of segment registers.  */
+  cs_base = user_reg_map_name_to_regnum (get_regcache_arch (regcache),
+                                         "cs_base", 7);
+  if (gdbarch_ptr_bit (gdbarch) == 32
+      && regnum >= cs_base && regnum <= cs_base + 5)
+    {
+      ULONGEST idx;
+      int base;
+
+      /* Get the idx.  */
+      base = user_reg_map_name_to_regnum (get_regcache_arch (regcache),
+                                          "cs", 2);
+      regcache_raw_read_unsigned (regcache,
+                                  regnum - cs_base + base,
+				  &idx);
+      idx >>= 3;
+
+      /* The base will be 0 if the idx is not TLS.  */
+      if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
+        {
+          regcache_raw_supply (regcache, regnum, NULL);
+          return;
+        }
+
+      /* Get the base.  */
+      if (ps_get_thread_area (NULL, tid, idx, (void *)&base) == PS_ERR)
+        perror_with_name (_("Couldn't get registers"));
+
+      regcache_raw_supply (regcache, regnum, &base);
+      return;
+    }
 }

 /* Store register REGNUM back into the child process.  If REGNUM is
--- a/features/i386/32bit-linux.xml
+++ b/features/i386/32bit-linux.xml
@@ -8,4 +8,10 @@
 <!DOCTYPE feature SYSTEM "gdb-target.dtd">
 <feature name="org.gnu.gdb.i386.linux">
   <reg name="orig_eax" bitsize="32" type="int" regnum="41"/>
+  <reg name="cs_base" bitsize="32" type="int"/>
+  <reg name="ss_base" bitsize="32" type="int"/>
+  <reg name="ds_base" bitsize="32" type="int"/>
+  <reg name="es_base" bitsize="32" type="int"/>
+  <reg name="fs_base" bitsize="32" type="int"/>
+  <reg name="gs_base" bitsize="32" type="int"/>
 </feature>
--- a/features/i386/i386-linux.c
+++ b/features/i386/i386-linux.c
@@ -71,6 +71,12 @@ initialize_tdesc_i386_linux (void)

   feature = tdesc_create_feature (result, "org.gnu.gdb.i386.linux");
   tdesc_create_reg (feature, "orig_eax", 41, 1, NULL, 32, "int");
+  tdesc_create_reg (feature, "cs_base", 42, 1, NULL, 32, "int");
+  tdesc_create_reg (feature, "ss_base", 43, 1, NULL, 32, "int");
+  tdesc_create_reg (feature, "ds_base", 44, 1, NULL, 32, "int");
+  tdesc_create_reg (feature, "es_base", 45, 1, NULL, 32, "int");
+  tdesc_create_reg (feature, "fs_base", 46, 1, NULL, 32, "int");
+  tdesc_create_reg (feature, "gs_base", 47, 1, NULL, 32, "int");

   feature = tdesc_create_feature (result, "org.gnu.gdb.i386.sse");
   field_type = tdesc_named_type (feature, "ieee_single");
--- a/i386-linux-nat.c
+++ b/i386-linux-nat.c
@@ -26,6 +26,7 @@
 #include "regset.h"
 #include "target.h"
 #include "linux-nat.h"
+#include "user-regs.h"

 #include "gdb_assert.h"
 #include "gdb_string.h"
@@ -506,11 +507,19 @@ static int store_fpxregs (const struct r
    this for all registers (including the floating point and SSE
    registers).  */

+#define GDT_ENTRY_TLS_ENTRIES	3
+#define GDT_ENTRY_TLS_MIN	6
+#define GDT_ENTRY_TLS_MAX 	(GDT_ENTRY_TLS_MIN + GDT_ENTRY_TLS_ENTRIES - 1)
+
+extern ps_err_e ps_get_thread_area (const struct ps_prochandle *ph,
+		                    lwpid_t lwpid, int idx, void **base);
+
 static void
 i386_linux_fetch_inferior_registers (struct target_ops *ops,
 				     struct regcache *regcache, int regno)
 {
   int tid;
+  int cs_base;

   /* Use the old method of peeking around in `struct user' if the
      GETREGS request isn't available.  */
@@ -580,6 +589,37 @@ i386_linux_fetch_inferior_registers (str
       return;
     }

+  /* Get the base of segment registers.  */
+  cs_base = user_reg_map_name_to_regnum (get_regcache_arch (regcache),
+                                         "cs_base", 7);
+  if (regno >= cs_base && regno <= cs_base + 5)
+    {
+      ULONGEST idx;
+      int base;
+
+      /* Get the idx.  */
+      base = user_reg_map_name_to_regnum (get_regcache_arch (regcache),
+                                          "cs", 2);
+      regcache_raw_read_unsigned (regcache,
+                                  regno - cs_base + base,
+				  &idx);
+      idx >>= 3;
+
+      /* The base will be 0 if the idx is not TLS.  */
+      if (idx < GDT_ENTRY_TLS_MIN || idx > GDT_ENTRY_TLS_MAX)
+        {
+          regcache_raw_supply (regcache, regno, NULL);
+          return;
+        }
+
+      /* Get the base.  */
+      if (ps_get_thread_area (NULL, tid, idx, (void *)&base) == PS_ERR)
+        perror_with_name (_("Couldn't get registers"));
+
+      regcache_raw_supply (regcache, regno, &base);
+      return;
+    }
+
   internal_error (__FILE__, __LINE__,
 		  _("Got request for bad register number %d."), regno);
 }
--- a/i386-linux-tdep.c
+++ b/i386-linux-tdep.c
@@ -42,6 +42,8 @@
 #include "i387-tdep.h"
 #include "i386-xstate.h"

+#include "user-regs.h"
+
 /* The syscall's XML filename for i386.  */
 #define XML_SYSCALL_FILENAME_I386 "syscalls/i386-linux.xml"

@@ -81,6 +83,12 @@ static int
 i386_linux_register_reggroup_p (struct gdbarch *gdbarch, int regnum,
 				struct reggroup *group)
 {
+  int cs_base = user_reg_map_name_to_regnum (gdbarch,
+                                             "cs_base", 7);
+
+  if (regnum >= cs_base && regnum <= cs_base + 5)
+    return (group == all_reggroup);
+
   if (regnum == I386_LINUX_ORIG_EAX_REGNUM)
     return (group == system_reggroup
 	    || group == save_reggroup

Re: [RFA] i386 segment base support

[Mark Kettenis]

> From: Hui Zhu <teawater@gmail.com>
> Date: Thu, 20 May 2010 15:34:17 +0800
> 
> Hi guys,
> 
> I update the old patch that I post to support segment base value.

Sorry, but we still need to discuss what programming model you intend
to support before I will consider looking at diffs.

Currently, on i386, GDB supports a fully flat 32-bit model, with one
small exception on platforms that support thread-local-storage.  In
that model you can assume that all the segment bases are 0 except for
%gs.  If that's all that people are interested in, I don't think we
should bother with segment bases for %cs, %ds, %es, %fs and %ss.

If people want to support fully segmented memory in GDB, then what you
propose is probably not enough, at least not for 32-bit mode.

Re: [RFA] i386 segment base support

[Hui Zhu]

On Thu, May 20, 2010 at 16:19, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> From: Hui Zhu <teawater@gmail.com>
>> Date: Thu, 20 May 2010 15:34:17 +0800
>>
>> Hi guys,
>>
>> I update the old patch that I post to support segment base value.
>
> Sorry, but we still need to discuss what programming model you intend
> to support before I will consider looking at diffs.
>
> Currently, on i386, GDB supports a fully flat 32-bit model, with one
> small exception on platforms that support thread-local-storage.  In
> that model you can assume that all the segment bases are 0 except for
> %gs.  If that's all that people are interested in, I don't think we
> should bother with segment bases for %cs, %ds, %es, %fs and %ss.
>
> If people want to support fully segmented memory in GDB, then what you
> propose is probably not enough, at least not for 32-bit mode.
>

I have a very, very need the value of segment base register.  Do you
have some good idea to put this value from target part
(i386-linux-nat) to gdbarch part (prec)?

Thanks,
Hui

Re: [RFA] i386 segment base support

[Daniel Jacobowitz]

On Thu, May 20, 2010 at 10:19:54AM +0200, Mark Kettenis wrote:
> Sorry, but we still need to discuss what programming model you intend
> to support before I will consider looking at diffs.
> 
> Currently, on i386, GDB supports a fully flat 32-bit model, with one
> small exception on platforms that support thread-local-storage.  In
> that model you can assume that all the segment bases are 0 except for
> %gs.  If that's all that people are interested in, I don't think we
> should bother with segment bases for %cs, %ds, %es, %fs and %ss.
> 
> If people want to support fully segmented memory in GDB, then what you
> propose is probably not enough, at least not for 32-bit mode.

This position confuses me.  Isn't "very limited support for segmented
memory" better than "no support for segmented memory"?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] i386 segment base support

[Mark Kettenis]

> Date: Thu, 20 May 2010 08:54:37 -0400
> From: Daniel Jacobowitz <dan@codesourcery.com>
> 
> On Thu, May 20, 2010 at 10:19:54AM +0200, Mark Kettenis wrote:
> > Sorry, but we still need to discuss what programming model you intend
> > to support before I will consider looking at diffs.
> > 
> > Currently, on i386, GDB supports a fully flat 32-bit model, with one
> > small exception on platforms that support thread-local-storage.  In
> > that model you can assume that all the segment bases are 0 except for
> > %gs.  If that's all that people are interested in, I don't think we
> > should bother with segment bases for %cs, %ds, %es, %fs and %ss.
> > 
> > If people want to support fully segmented memory in GDB, then what you
> > propose is probably not enough, at least not for 32-bit mode.
> 
> This position confuses me.  Isn't "very limited support for segmented
> memory" better than "no support for segmented memory"?

I'm not taking a position here.  I'm trying to figure out what people
want out of this.  If it is only about supporting TLS for Linux
userland binaries we can have a radically simpler solution than when
people want full fledged kernel-style segment register manipulating
code to work as well.

Re: [RFA] i386 segment base support

[Daniel Jacobowitz]

On Thu, May 20, 2010 at 04:39:29PM +0200, Mark Kettenis wrote:
> I'm not taking a position here.  I'm trying to figure out what people
> want out of this.  If it is only about supporting TLS for Linux
> userland binaries we can have a radically simpler solution than when
> people want full fledged kernel-style segment register manipulating
> code to work as well.

I don't have a vested interest in either, but I think that the full
fledged version is a good goal for GDB.  So even if we aren't going to
get there today, I'd favor an approach to the segment registers that
moves us in that direction.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFA] i386 segment base support

[Hui Zhu]

On Thu, May 20, 2010 at 22:39, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Thu, 20 May 2010 08:54:37 -0400
>> From: Daniel Jacobowitz <dan@codesourcery.com>
>>
>> On Thu, May 20, 2010 at 10:19:54AM +0200, Mark Kettenis wrote:
>> > Sorry, but we still need to discuss what programming model you intend
>> > to support before I will consider looking at diffs.
>> >
>> > Currently, on i386, GDB supports a fully flat 32-bit model, with one
>> > small exception on platforms that support thread-local-storage.  In
>> > that model you can assume that all the segment bases are 0 except for
>> > %gs.  If that's all that people are interested in, I don't think we
>> > should bother with segment bases for %cs, %ds, %es, %fs and %ss.
>> >
>> > If people want to support fully segmented memory in GDB, then what you
>> > propose is probably not enough, at least not for 32-bit mode.
>>
>> This position confuses me.  Isn't "very limited support for segmented
>> memory" better than "no support for segmented memory"?
>
> I'm not taking a position here.  I'm trying to figure out what people
> want out of this.  If it is only about supporting TLS for Linux
> userland binaries we can have a radically simpler solution than when
> people want full fledged kernel-style segment register manipulating
> code to work as well.
>

My trouble is:
Prec is in the arch part, it cannot call target function directly.  It
need interface.

I just know 2 ways to handle it:
1. add interface to target.
2. add support to gdbarch.

I am very happy that you said have a simpler way to handle it?  Could
you tell me what or where is the simpler way?

Thanks,
Hui


This is what I send before:
http://sourceware.org/ml/gdb-patches/2010-03/msg00839.html
Prec just need the base to get the insn memory operate address.  Do
you think we need other message of segment?

If need, do we need divide all message like eflags?

Thanks,
Hui


http://sourceware.org/ml/gdb-patches/2010-04/msg00983.html
Prec must know the each base of segment register.

If you don't like it.  What about the old way that I use?  It doesn't
add anything to reg list.
But for the each way, we need add interface to the target part that
prec can get the value.

Thanks,
Hui


Follow is why I need it:
Hi,

In before, the prec cannot support the x86 segment register.  Because
GDB just have the interface to get the index the segment reg point to,
but cannot get the base in the segment.
Just the OS can get this value.

After I read some code of Linux kernel, I found that some code about
this issue in file common.c and segment.h, the x86-32 struct about it
is:
DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = {
#ifdef CONFIG_X86_64
       /*
        * We need valid kernel segments for data and code in long mode too
        * IRET will check the segment types  kkeil 2000/10/28
        * Also sysret mandates a special GDT layout
        *
        * TLS descriptors are currently at a different place compared to i386.
        * Hopefully nobody expects them at a fixed place (Wine?)
        */
       [GDT_ENTRY_KERNEL32_CS]         = GDT_ENTRY_INIT(0xc09b, 0, 0xfffff),
       [GDT_ENTRY_KERNEL_CS]           = GDT_ENTRY_INIT(0xa09b, 0, 0xfffff),
       [GDT_ENTRY_KERNEL_DS]           = GDT_ENTRY_INIT(0xc093, 0, 0xfffff),
       [GDT_ENTRY_DEFAULT_USER32_CS]   = GDT_ENTRY_INIT(0xc0fb, 0, 0xfffff),
       [GDT_ENTRY_DEFAULT_USER_DS]     = GDT_ENTRY_INIT(0xc0f3, 0, 0xfffff),
       [GDT_ENTRY_DEFAULT_USER_CS]     = GDT_ENTRY_INIT(0xa0fb, 0, 0xfffff),
#else
       [GDT_ENTRY_KERNEL_CS]           = GDT_ENTRY_INIT(0xc09a, 0, 0xfffff),
       [GDT_ENTRY_KERNEL_DS]           = GDT_ENTRY_INIT(0xc092, 0, 0xfffff),
       [GDT_ENTRY_DEFAULT_USER_CS]     = GDT_ENTRY_INIT(0xc0fa, 0, 0xfffff),
       [GDT_ENTRY_DEFAULT_USER_DS]     = GDT_ENTRY_INIT(0xc0f2, 0, 0xfffff),
       /*
        * Segments used for calling PnP BIOS have byte granularity.
        * They code segments and data segments have fixed 64k limits,
        * the transfer segment sizes are set at run time.
        */
       /* 32-bit code */
       [GDT_ENTRY_PNPBIOS_CS32 18]     = GDT_ENTRY_INIT(0x409a, 0, 0xffff),
       /* 16-bit code */
       [GDT_ENTRY_PNPBIOS_CS16 19]     = GDT_ENTRY_INIT(0x009a, 0, 0xffff),
       /* 16-bit data */
       [GDT_ENTRY_PNPBIOS_DS]          = GDT_ENTRY_INIT(0x0092, 0, 0xffff),
       /* 16-bit data */
       [GDT_ENTRY_PNPBIOS_TS1]         = GDT_ENTRY_INIT(0x0092, 0, 0),
       /* 16-bit data */
       [GDT_ENTRY_PNPBIOS_TS2]         = GDT_ENTRY_INIT(0x0092, 0, 0),
       /*
        * The APM segments have byte granularity and their bases
        * are set at run time.  All have 64k limits.
        */
       /* 32-bit code */
       [GDT_ENTRY_APMBIOS_BASE]        = GDT_ENTRY_INIT(0x409a, 0, 0xffff),
       /* 16-bit code */
       [GDT_ENTRY_APMBIOS_BASE+1]      = GDT_ENTRY_INIT(0x009a, 0, 0xffff),
       /* data */
       [GDT_ENTRY_APMBIOS_BASE+2]      = GDT_ENTRY_INIT(0x4092, 0, 0xffff),

       [GDT_ENTRY_ESPFIX_SS]           = GDT_ENTRY_INIT(0xc092, 0, 0xfffff),
       [GDT_ENTRY_PERCPU]              = GDT_ENTRY_INIT(0xc092, 0, 0xfffff),
       GDT_STACK_CANARY_INIT
#endif
} };

/*
 * The layout of the per-CPU GDT under Linux:
 *
 *   0 - null
 *   1 - reserved
 *   2 - reserved
 *   3 - reserved
 *
 *   4 - unused                 <==== new cacheline
 *   5 - unused
 *
 *  ------- start of TLS (Thread-Local Storage) segments:
 *
 *   6 - TLS segment #1                 [ glibc's TLS segment ]
 *   7 - TLS segment #2                 [ Wine's %fs Win32 segment ]
 *   8 - TLS segment #3
 *   9 - reserved
 *  10 - reserved
 *  11 - reserved
 *
 *  ------- start of kernel segments:
 *
 *  12 - kernel code segment            <==== new cacheline
 *  13 - kernel data segment
 *  14 - default user CS
 *  15 - default user DS
 *  16 - TSS
 *  17 - LDT
 *  18 - PNPBIOS support (16->32 gate)
 *  19 - PNPBIOS support
 *  20 - PNPBIOS support
 *  21 - PNPBIOS support
 *  22 - PNPBIOS support
 *  23 - APM BIOS support
 *  24 - APM BIOS support
 *  25 - APM BIOS support
 *
 *  26 - ESPFIX small SS
 *  27 - per-cpu                        [ offset to per-cpu data area ]
 *  28 - stack_canary-20                [ for stack protector ]
 *  29 - unused
 *  30 - unused
 *  31 - TSS for double fault handler
 */

So, most of base is 0.  Just 6 7 8 can be change.

And I found linux kernel x86-32 have system calls set_thread_area and
get_thread_area to set them's value.
I think let inferior call "get_thread_area" is support each target is
more better.  But I found ptrace have a interface
PTRACE_GET_THREAD_AREA to get the message of thread_area message and
ps_get_thread_area function of GDB use it.
So I choice call ps_get_thread_area to get the segment base.


For the amd64 linux, I did some small check about it, it didn't affect
by segment register issue most of time.  And it have PTRACE_ARCH_PRCTL
to support get base message.  When SSE patch is OK.  I will add patch
for them.

Thanks,
Hui