Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* Three weeks to branching (gdb 7.5 release)
@ 2012-05-11 18:17 Joel Brobecker
  2012-05-11 18:43 ` H.J. Lu
                   ` (2 more replies)
  0 siblings, 3 replies; 42+ messages in thread
From: Joel Brobecker @ 2012-05-11 18:17 UTC (permalink / raw)
  To: gdb-patches

Hello,

Just a quick heads up: The current tentative date for branching
GDB (7.5 release) is Mon Jun 4th, which is a little over three weeks
away.

I've created a wiki page for known issues that need to be fixed
before then:

    http://sourceware.org/gdb/wiki/GDB_7.5_Release

When you add an issue, please make sure you add a name so we know
who is coordinating the effort.  If you don't know who can work
on it, please just post the issue here, and we'll try to find some
help.

I only know of one issue, which is a noticeable performance degradation
that was reported a while ago:

    http://sourceware.org/bugzilla/show_bug.cgi?id=14002

There is a workaround, so could possibly considered NOT blocking
for the release.

Tom, I put you as the main lead on this one, with ???, as one
of your commits was identified as the one after which the slow-
down is noticed. It's a first guess; we can re-assign, including
to myself, if you'd like.

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-11 18:17 Three weeks to branching (gdb 7.5 release) Joel Brobecker
@ 2012-05-11 18:43 ` H.J. Lu
  2012-05-14 14:45   ` Joel Brobecker
  2012-05-20 15:40   ` H.J. Lu
  2012-05-12 15:26 ` Three weeks to branching (gdb 7.5 release) Doug Evans
  2012-05-29 17:17 ` Three weeks to branching (gdb 7.5 release) Jan Kratochvil
  2 siblings, 2 replies; 42+ messages in thread
From: H.J. Lu @ 2012-05-11 18:43 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello,
>
> Just a quick heads up: The current tentative date for branching
> GDB (7.5 release) is Mon Jun 4th, which is a little over three weeks
> away.
>
> I've created a wiki page for known issues that need to be fixed
> before then:
>
>    http://sourceware.org/gdb/wiki/GDB_7.5_Release
>
> When you add an issue, please make sure you add a name so we know
> who is coordinating the effort.  If you don't know who can work
> on it, please just post the issue here, and we'll try to find some
> help.
>
> I only know of one issue, which is a noticeable performance degradation
> that was reported a while ago:
>

I'd like to merge x32 into GDB 7.5.  My x32 change is on hjl/x32/master
branch at

http://sourceware.org/git/?p=gdb.git;a=summary

The current diff only has 864 lines.  One patch:

http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html

isn't reviewed yet.  I will open a meta bug for x32 integration.

Thanks.


H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-11 18:17 Three weeks to branching (gdb 7.5 release) Joel Brobecker
  2012-05-11 18:43 ` H.J. Lu
@ 2012-05-12 15:26 ` Doug Evans
  2012-05-20 14:59   ` Doug Evans
  2012-05-29 17:17 ` Three weeks to branching (gdb 7.5 release) Jan Kratochvil
  2 siblings, 1 reply; 42+ messages in thread
From: Doug Evans @ 2012-05-12 15:26 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> I only know of one issue, which is a noticeable performance degradation
> that was reported a while ago:
>
>    http://sourceware.org/bugzilla/show_bug.cgi?id=14002
>
> There is a workaround, so could possibly considered NOT blocking
> for the release.
>
> Tom, I put you as the main lead on this one, with ???, as one
> of your commits was identified as the one after which the slow-
> down is noticed. It's a first guess; we can re-assign, including
> to myself, if you'd like.

I'm working on it as well.
I fixed one significant memory issue post 7.4, and there's more I'd
like to do, hopefully for 7.5.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-11 18:43 ` H.J. Lu
@ 2012-05-14 14:45   ` Joel Brobecker
  2012-05-20 15:40   ` H.J. Lu
  1 sibling, 0 replies; 42+ messages in thread
From: Joel Brobecker @ 2012-05-14 14:45 UTC (permalink / raw)
  To: H.J. Lu; +Cc: gdb-patches

> I'd like to merge x32 into GDB 7.5.  My x32 change is on hjl/x32/master
> branch at

Ack. My recommendation is to try to get your patches in by the deadline.
If there are one or two small ones that didn't make it but are close,
we can wait a few extra days.

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-12 15:26 ` Three weeks to branching (gdb 7.5 release) Doug Evans
@ 2012-05-20 14:59   ` Doug Evans
  2012-06-11 15:35     ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
  0 siblings, 1 reply; 42+ messages in thread
From: Doug Evans @ 2012-05-20 14:59 UTC (permalink / raw)
  To: Joel Brobecker, Tom Tromey; +Cc: gdb-patches

On Sat, May 12, 2012 at 8:26 AM, Doug Evans <dje@google.com> wrote:
> On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> I only know of one issue, which is a noticeable performance degradation
>> that was reported a while ago:
>>
>>    http://sourceware.org/bugzilla/show_bug.cgi?id=14002
>>
>> There is a workaround, so could possibly considered NOT blocking
>> for the release.
>>
>> Tom, I put you as the main lead on this one, with ???, as one
>> of your commits was identified as the one after which the slow-
>> down is noticed. It's a first guess; we can re-assign, including
>> to myself, if you'd like.
>
> I'm working on it as well.
> I fixed one significant memory issue post 7.4, and there's more I'd
> like to do, hopefully for 7.5.

I've replaced Tom's name with mine for 14002, as I'm now actively working on it.

I've also added 14125 which I also want to have fixed for 7.5, and I'm
working on that too.
For that my plan is to add a "bit" (TBD if it's just a bit) that
specifies for each symbol whether it's in GLOBAL_BLOCK or
STATIC_BLOCK.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-11 18:43 ` H.J. Lu
  2012-05-14 14:45   ` Joel Brobecker
@ 2012-05-20 15:40   ` H.J. Lu
  2012-05-20 20:44     ` Mark Kettenis
  1 sibling, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2012-05-20 15:40 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

On Fri, May 11, 2012 at 11:43 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Hello,
>>
>> Just a quick heads up: The current tentative date for branching
>> GDB (7.5 release) is Mon Jun 4th, which is a little over three weeks
>> away.
>>
>> I've created a wiki page for known issues that need to be fixed
>> before then:
>>
>>    http://sourceware.org/gdb/wiki/GDB_7.5_Release
>>
>> When you add an issue, please make sure you add a name so we know
>> who is coordinating the effort.  If you don't know who can work
>> on it, please just post the issue here, and we'll try to find some
>> help.
>>
>> I only know of one issue, which is a noticeable performance degradation
>> that was reported a while ago:
>>
>
> I'd like to merge x32 into GDB 7.5.  My x32 change is on hjl/x32/master
> branch at
>
> http://sourceware.org/git/?p=gdb.git;a=summary
>
> The current diff only has 864 lines.  One patch:
>
> http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
>
> isn't reviewed yet.  I will open a meta bug for x32 integration.
>

I opened:

http://sourceware.org/bugzilla/show_bug.cgi?id=14099

Thanks for help from everyone.  The full GDBserver x32 support
as well as partial GDB x32 support have been checked in.  The
remaining patches are:

http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html
http://sourceware.org/ml/gdb-patches/2012-04/msg00191.html
http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html
http://sourceware.org/ml/gdb-patches/2012-05/msg00531.html
http://sourceware.org/ml/gdb-patches/2012-05/msg00533.html
http://sourceware.org/ml/gdb-patches/2012-05/msg00489.html
http://sourceware.org/ml/gdb-patches/2012-05/msg00438.html
http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html

I would appreciate help to get them reviewed and approved.

Thanks.

-- 
H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-20 15:40   ` H.J. Lu
@ 2012-05-20 20:44     ` Mark Kettenis
  2012-05-20 21:25       ` H.J. Lu
  0 siblings, 1 reply; 42+ messages in thread
From: Mark Kettenis @ 2012-05-20 20:44 UTC (permalink / raw)
  To: hjl.tools; +Cc: brobecker, gdb-patches

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7238 bytes --]

> Date: Sun, 20 May 2012 08:40:26 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> On Fri, May 11, 2012 at 11:43 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> >> Hello,
> >>
> >> Just a quick heads up: The current tentative date for branching
> >> GDB (7.5 release) is Mon Jun 4th, which is a little over three weeks
> >> away.
> >>
> >> I've created a wiki page for known issues that need to be fixed
> >> before then:
> >>
> >>    http://sourceware.org/gdb/wiki/GDB_7.5_Release
> >>
> >> When you add an issue, please make sure you add a name so we know
> >> who is coordinating the effort.  If you don't know who can work
> >> on it, please just post the issue here, and we'll try to find some
> >> help.
> >>
> >> I only know of one issue, which is a noticeable performance degradation
> >> that was reported a while ago:
> >>
> >
> > I'd like to merge x32 into GDB 7.5.  My x32 change is on hjl/x32/master
> > branch at
> >
> > http://sourceware.org/git/?p=gdb.git;a=summary
> >
> > The current diff only has 864 lines.  One patch:
> >
> > http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
> >
> > isn't reviewed yet.  I will open a meta bug for x32 integration.
> >
> 
> I opened:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=14099
> 
> Thanks for help from everyone.  The full GDBserver x32 support
> as well as partial GDB x32 support have been checked in.  The
> remaining patches are:
> 
> http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html
> http://sourceware.org/ml/gdb-patches/2012-04/msg00191.html
> http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html
> http://sourceware.org/ml/gdb-patches/2012-05/msg00531.html
> http://sourceware.org/ml/gdb-patches/2012-05/msg00533.html
> http://sourceware.org/ml/gdb-patches/2012-05/msg00489.html
> http://sourceware.org/ml/gdb-patches/2012-05/msg00438.html
> http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
> 
> I would appreciate help to get them reviewed and approved.

As I wrote before, I don't think adding lots if if-statements is the
proper way to add a new ABI to GDB.  The proper way is to do it like
the diff below.  In that diff, I'm not entirely confident that calling
amd64_linux_init_abi() from amd64_x32_linux_init_abi() makes all that
much sense.  For example the amd64_linux_record_tdep stuff probably
isn't right for the x32 ABI.  But at least this will give us a
starting point where we won't end up adding 

  if (gdbarch_ptr_bit (gdbarch) == 32)
    {
      ...
    }
  else
    {
    }

blocks all over the place.



Index: amd64-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
retrieving revision 1.50
diff -u -p -r1.50 amd64-linux-tdep.c
--- amd64-linux-tdep.c	12 May 2012 08:54:03 -0000	1.50
+++ amd64-linux-tdep.c	20 May 2012 20:31:53 -0000
@@ -1543,6 +1543,24 @@ amd64_linux_init_abi (struct gdbarch_inf
 
   tdep->i386_syscall_record = amd64_linux_syscall_record;
 }
+
+static void
+amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+
+  amd64_linux_init_abi (info, gdbarch);
+  amd64_x32_init_abi (info, gdbarch);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_amd64_linux;
+  tdep->tdesc = tdesc;
+
+  /* GNU/Linux uses SVR4-style shared libraries.  */
+  set_solib_svr4_fetch_link_map_offsets
+    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
+}
 \f
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
@@ -1553,6 +1571,8 @@ _initialize_amd64_linux_tdep (void)
 {
   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
 			  GDB_OSABI_LINUX, amd64_linux_init_abi);
+  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
+			  GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
 
   /* Initialize the Linux target description.  */
   initialize_tdesc_amd64_linux ();
Index: amd64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
retrieving revision 1.104
diff -u -p -r1.104 amd64-tdep.c
--- amd64-tdep.c	14 May 2012 18:56:40 -0000	1.104
+++ amd64-tdep.c	20 May 2012 20:31:54 -0000
@@ -258,7 +258,8 @@ static const char *amd64_word_names[] =
 static const char *amd64_dword_names[] =
 {
   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp", 
-  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
+  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
+  "eip"
 };
 
 /* Return the name of register REGNUM.  */
@@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info
   set_gdbarch_stap_parse_special_token (gdbarch,
 					i386_stap_parse_special_token);
 }
+\f
+
+static struct type *
+amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  switch (regnum - tdep->eax_regnum)
+    {
+    case AMD64_RBP_REGNUM:	/* %ebp */
+    case AMD64_RSP_REGNUM:	/* %esp */
+      return builtin_type (gdbarch)->builtin_data_ptr;
+    case AMD64_RIP_REGNUM:	/* %eip */
+      return builtin_type (gdbarch)->builtin_func_ptr;
+    }
+
+  return i386_pseudo_register_type (gdbarch, regnum);
+}
+
+void
+amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+
+  amd64_init_abi (info, gdbarch);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_x32;
+  tdep->tdesc = tdesc;
+
+  tdep->num_dword_regs = 17;
+  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
+
+  set_gdbarch_long_bit (gdbarch, 32);
+  set_gdbarch_ptr_bit (gdbarch, 32);
+}
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
 void _initialize_amd64_tdep (void);
Index: amd64-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.h,v
retrieving revision 1.21
diff -u -p -r1.21 amd64-tdep.h
--- amd64-tdep.h	4 Jan 2012 08:16:56 -0000	1.21
+++ amd64-tdep.h	20 May 2012 20:31:54 -0000
@@ -80,6 +80,8 @@ extern void amd64_displaced_step_fixup (
 					struct regcache *regs);
 
 extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
+extern void amd64_x32_init_abi (struct gdbarch_info info,
+				struct gdbarch *gdbarch);
 
 /* Fill register REGNUM in REGCACHE with the appropriate
    floating-point or SSE register value from *FXSAVE.  If REGNUM is
Index: i386-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.h,v
retrieving revision 1.78
diff -u -p -r1.78 i386-tdep.h
--- i386-tdep.h	27 Apr 2012 20:47:54 -0000	1.78
+++ i386-tdep.h	20 May 2012 20:31:57 -0000
@@ -309,6 +309,8 @@ extern int i386_ymm_regnum_p (struct gdb
 
 extern const char *i386_pseudo_register_name (struct gdbarch *gdbarch,
 					      int regnum);
+extern struct type *i386_pseudo_register_type (struct gdbarch *gdbarch,
+					       int regnum);
 
 extern void i386_pseudo_register_read_into_value (struct gdbarch *gdbarch,
 						  struct regcache *regcache,


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-20 20:44     ` Mark Kettenis
@ 2012-05-20 21:25       ` H.J. Lu
  2012-05-20 21:39         ` Mark Kettenis
  0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2012-05-20 21:25 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: brobecker, gdb-patches

On Sun, May 20, 2012 at 1:43 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Sun, 20 May 2012 08:40:26 -0700
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>
>> On Fri, May 11, 2012 at 11:43 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> >> Hello,
>> >>
>> >> Just a quick heads up: The current tentative date for branching
>> >> GDB (7.5 release) is Mon Jun 4th, which is a little over three weeks
>> >> away.
>> >>
>> >> I've created a wiki page for known issues that need to be fixed
>> >> before then:
>> >>
>> >>    http://sourceware.org/gdb/wiki/GDB_7.5_Release
>> >>
>> >> When you add an issue, please make sure you add a name so we know
>> >> who is coordinating the effort.  If you don't know who can work
>> >> on it, please just post the issue here, and we'll try to find some
>> >> help.
>> >>
>> >> I only know of one issue, which is a noticeable performance degradation
>> >> that was reported a while ago:
>> >>
>> >
>> > I'd like to merge x32 into GDB 7.5.  My x32 change is on hjl/x32/master
>> > branch at
>> >
>> > http://sourceware.org/git/?p=gdb.git;a=summary
>> >
>> > The current diff only has 864 lines.  One patch:
>> >
>> > http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
>> >
>> > isn't reviewed yet.  I will open a meta bug for x32 integration.
>> >
>>
>> I opened:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=14099
>>
>> Thanks for help from everyone.  The full GDBserver x32 support
>> as well as partial GDB x32 support have been checked in.  The
>> remaining patches are:
>>
>> http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html
>> http://sourceware.org/ml/gdb-patches/2012-04/msg00191.html
>> http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html
>> http://sourceware.org/ml/gdb-patches/2012-05/msg00531.html
>> http://sourceware.org/ml/gdb-patches/2012-05/msg00533.html
>> http://sourceware.org/ml/gdb-patches/2012-05/msg00489.html
>> http://sourceware.org/ml/gdb-patches/2012-05/msg00438.html
>> http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
>>
>> I would appreciate help to get them reviewed and approved.
>
> As I wrote before, I don't think adding lots if if-statements is the
> proper way to add a new ABI to GDB.  The proper way is to do it like
> the diff below.  In that diff, I'm not entirely confident that calling
> amd64_linux_init_abi() from amd64_x32_linux_init_abi() makes all that
> much sense.  For example the amd64_linux_record_tdep stuff probably
> isn't right for the x32 ABI.  But at least this will give us a
> starting point where we won't end up adding
>
>  if (gdbarch_ptr_bit (gdbarch) == 32)
>    {
>      ...
>    }

Please take a look at

http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html

It doesn't add any  (gdbarch_ptr_bit (gdbarch) == 32).  It just changes
it to bits_per_word.  I add one  "gdbarch_ptr_bit (gdbarch) == 32" in
amd64_linux_sigtramp_start and I will remove them from

http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html

>  else
>    {
>    }
>
> blocks all over the place.
>
>
>
> Index: amd64-linux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 amd64-linux-tdep.c
> --- amd64-linux-tdep.c  12 May 2012 08:54:03 -0000      1.50
> +++ amd64-linux-tdep.c  20 May 2012 20:31:53 -0000
> @@ -1543,6 +1543,24 @@ amd64_linux_init_abi (struct gdbarch_inf
>
>   tdep->i386_syscall_record = amd64_linux_syscall_record;
>  }
> +
> +static void
> +amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +
> +  amd64_linux_init_abi (info, gdbarch);
> +  amd64_x32_init_abi (info, gdbarch);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_amd64_linux;

I assume you meant tdesc_x32_linux here.  The problem is
when we reach here, if (! tdesc_has_registers (tdesc)) will always
be false since tdep->tdesc has been set by amd64_linux_init_abi.

> +  tdep->tdesc = tdesc;
> +
> +  /* GNU/Linux uses SVR4-style shared libraries.  */
> +  set_solib_svr4_fetch_link_map_offsets
> +    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
> +}
>
>
>  /* Provide a prototype to silence -Wmissing-prototypes.  */
> @@ -1553,6 +1571,8 @@ _initialize_amd64_linux_tdep (void)
>  {
>   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
>                          GDB_OSABI_LINUX, amd64_linux_init_abi);
> +  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
> +                         GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
>
>   /* Initialize the Linux target description.  */
>   initialize_tdesc_amd64_linux ();
> Index: amd64-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 amd64-tdep.c
> --- amd64-tdep.c        14 May 2012 18:56:40 -0000      1.104
> +++ amd64-tdep.c        20 May 2012 20:31:54 -0000
> @@ -258,7 +258,8 @@ static const char *amd64_word_names[] =
>  static const char *amd64_dword_names[] =
>  {
>   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp",
> -  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
> +  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
> +  "eip"
>  };
>
>  /* Return the name of register REGNUM.  */
> @@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info
>   set_gdbarch_stap_parse_special_token (gdbarch,
>                                        i386_stap_parse_special_token);
>  }
> +
> +
> +static struct type *
> +amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +
> +  switch (regnum - tdep->eax_regnum)
> +    {
> +    case AMD64_RBP_REGNUM:     /* %ebp */
> +    case AMD64_RSP_REGNUM:     /* %esp */
> +      return builtin_type (gdbarch)->builtin_data_ptr;
> +    case AMD64_RIP_REGNUM:     /* %eip */
> +      return builtin_type (gdbarch)->builtin_func_ptr;
> +    }
> +
> +  return i386_pseudo_register_type (gdbarch, regnum);
> +}
> +
> +void
> +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +
> +  amd64_init_abi (info, gdbarch);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_x32;

Again, " if (! tdesc_has_registers (tdesc))" will always false
since tdep->tdesc has been set in amd64_init_abi.  How
do we solve it?  My suggestion is to add a new function
which is similar to amd64_init_abi, but takes a new argument,
const struct target_desc *, as the default tdesc. Both
amd64_init_abi and amd64_x32_init_abi will call this
function.  Will it work for you?

Thanks.


-- 
H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-20 21:25       ` H.J. Lu
@ 2012-05-20 21:39         ` Mark Kettenis
  2012-05-20 22:49           ` H.J. Lu
  0 siblings, 1 reply; 42+ messages in thread
From: Mark Kettenis @ 2012-05-20 21:39 UTC (permalink / raw)
  To: hjl.tools; +Cc: brobecker, gdb-patches

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7567 bytes --]

> Date: Sun, 20 May 2012 14:24:46 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> On Sun, May 20, 2012 at 1:43 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >> Date: Sun, 20 May 2012 08:40:26 -0700
> >> From: "H.J. Lu" <hjl.tools@gmail.com>
> >>
> >> On Fri, May 11, 2012 at 11:43 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> >> > On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> >> >> Hello,
> >> >>
> >> >> Just a quick heads up: The current tentative date for branching
> >> >> GDB (7.5 release) is Mon Jun 4th, which is a little over three weeks
> >> >> away.
> >> >>
> >> >> I've created a wiki page for known issues that need to be fixed
> >> >> before then:
> >> >>
> >> >>    http://sourceware.org/gdb/wiki/GDB_7.5_Release
> >> >>
> >> >> When you add an issue, please make sure you add a name so we know
> >> >> who is coordinating the effort.  If you don't know who can work
> >> >> on it, please just post the issue here, and we'll try to find some
> >> >> help.
> >> >>
> >> >> I only know of one issue, which is a noticeable performance degradation
> >> >> that was reported a while ago:
> >> >>
> >> >
> >> > I'd like to merge x32 into GDB 7.5.  My x32 change is on hjl/x32/master
> >> > branch at
> >> >
> >> > http://sourceware.org/git/?p=gdb.git;a=summary
> >> >
> >> > The current diff only has 864 lines.  One patch:
> >> >
> >> > http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
> >> >
> >> > isn't reviewed yet.  I will open a meta bug for x32 integration.
> >> >
> >>
> >> I opened:
> >>
> >> http://sourceware.org/bugzilla/show_bug.cgi?id=14099
> >>
> >> Thanks for help from everyone.  The full GDBserver x32 support
> >> as well as partial GDB x32 support have been checked in.  The
> >> remaining patches are:
> >>
> >> http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html
> >> http://sourceware.org/ml/gdb-patches/2012-04/msg00191.html
> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html
> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00531.html
> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00533.html
> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00489.html
> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00438.html
> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
> >>
> >> I would appreciate help to get them reviewed and approved.
> >
> > As I wrote before, I don't think adding lots if if-statements is the
> > proper way to add a new ABI to GDB.  The proper way is to do it like
> > the diff below.  In that diff, I'm not entirely confident that calling
> > amd64_linux_init_abi() from amd64_x32_linux_init_abi() makes all that
> > much sense.  For example the amd64_linux_record_tdep stuff probably
> > isn't right for the x32 ABI.  But at least this will give us a
> > starting point where we won't end up adding
> >
> >  if (gdbarch_ptr_bit (gdbarch) == 32)
> >    {
> >      ...
> >    }
> 
> Please take a look at
> 
> http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html
> 
> It doesn't add any  (gdbarch_ptr_bit (gdbarch) == 32).  It just changes
> it to bits_per_word.  I add one  "gdbarch_ptr_bit (gdbarch) == 32" in
> amd64_linux_sigtramp_start and I will remove them from
> 
> http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html

Well, I'm also thining about the future here.  Stuff you haven't
addressed yet in your diff series and stuff that will be added later.

> > Index: amd64-linux-tdep.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
> > retrieving revision 1.50
> > diff -u -p -r1.50 amd64-linux-tdep.c
> > --- amd64-linux-tdep.c  12 May 2012 08:54:03 -0000      1.50
> > +++ amd64-linux-tdep.c  20 May 2012 20:31:53 -0000
> > @@ -1543,6 +1543,24 @@ amd64_linux_init_abi (struct gdbarch_inf
> >
> >   tdep->i386_syscall_record = amd64_linux_syscall_record;
> >  }
> > +
> > +static void
> > +amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
> > +{
> > +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> > +  const struct target_desc *tdesc = info.target_desc;
> > +
> > +  amd64_linux_init_abi (info, gdbarch);
> > +  amd64_x32_init_abi (info, gdbarch);
> > +
> > +  if (! tdesc_has_registers (tdesc))
> > +    tdesc = tdesc_amd64_linux;
> 
> I assume you meant tdesc_x32_linux here.  The problem is
> when we reach here, if (! tdesc_has_registers (tdesc)) will always
> be false since tdep->tdesc has been set by amd64_linux_init_abi.
> 
> > +  tdep->tdesc = tdesc;
> > +
> > +  /* GNU/Linux uses SVR4-style shared libraries.  */
> > +  set_solib_svr4_fetch_link_map_offsets
> > +    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
> > +}
> >
> >
> >  /* Provide a prototype to silence -Wmissing-prototypes.  */
> > @@ -1553,6 +1571,8 @@ _initialize_amd64_linux_tdep (void)
> >  {
> >   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
> >                          GDB_OSABI_LINUX, amd64_linux_init_abi);
> > +  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
> > +                         GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
> >
> >   /* Initialize the Linux target description.  */
> >   initialize_tdesc_amd64_linux ();
> > Index: amd64-tdep.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
> > retrieving revision 1.104
> > diff -u -p -r1.104 amd64-tdep.c
> > --- amd64-tdep.c        14 May 2012 18:56:40 -0000      1.104
> > +++ amd64-tdep.c        20 May 2012 20:31:54 -0000
> > @@ -258,7 +258,8 @@ static const char *amd64_word_names[] =
> >  static const char *amd64_dword_names[] =
> >  {
> >   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp",
> > -  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
> > +  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
> > +  "eip"
> >  };
> >
> >  /* Return the name of register REGNUM.  */
> > @@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info
> >   set_gdbarch_stap_parse_special_token (gdbarch,
> >                                        i386_stap_parse_special_token);
> >  }
> > +
> > +
> > +static struct type *
> > +amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
> > +{
> > +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> > +
> > +  switch (regnum - tdep->eax_regnum)
> > +    {
> > +    case AMD64_RBP_REGNUM:     /* %ebp */
> > +    case AMD64_RSP_REGNUM:     /* %esp */
> > +      return builtin_type (gdbarch)->builtin_data_ptr;
> > +    case AMD64_RIP_REGNUM:     /* %eip */
> > +      return builtin_type (gdbarch)->builtin_func_ptr;
> > +    }
> > +
> > +  return i386_pseudo_register_type (gdbarch, regnum);
> > +}
> > +
> > +void
> > +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> > +{
> > +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> > +  const struct target_desc *tdesc = info.target_desc;
> > +
> > +  amd64_init_abi (info, gdbarch);
> > +
> > +  if (! tdesc_has_registers (tdesc))
> > +    tdesc = tdesc_x32;
> 
> Again, " if (! tdesc_has_registers (tdesc))" will always false
> since tdep->tdesc has been set in amd64_init_abi.

I don't think that's true.  Here tdesc comes from info.target_desc,
not tdep->tdesc, so the check should still do the right thing.  In
fact it must do the right thing, since amd64_linux_init_abi() does the
same thing already.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-20 21:39         ` Mark Kettenis
@ 2012-05-20 22:49           ` H.J. Lu
  2012-05-25 16:52             ` H.J. Lu
  2012-05-28 20:26             ` x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release)) Mark Kettenis
  0 siblings, 2 replies; 42+ messages in thread
From: H.J. Lu @ 2012-05-20 22:49 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: brobecker, gdb-patches

On Sun, May 20, 2012 at 2:38 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Sun, 20 May 2012 14:24:46 -0700
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>
>> On Sun, May 20, 2012 at 1:43 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> >> Date: Sun, 20 May 2012 08:40:26 -0700
>> >> From: "H.J. Lu" <hjl.tools@gmail.com>
>> >>
>> >> On Fri, May 11, 2012 at 11:43 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> >> > On Fri, May 11, 2012 at 11:17 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> >> >> Hello,
>> >> >>
>> >> >> Just a quick heads up: The current tentative date for branching
>> >> >> GDB (7.5 release) is Mon Jun 4th, which is a little over three weeks
>> >> >> away.
>> >> >>
>> >> >> I've created a wiki page for known issues that need to be fixed
>> >> >> before then:
>> >> >>
>> >> >> á áhttp://sourceware.org/gdb/wiki/GDB_7.5_Release
>> >> >>
>> >> >> When you add an issue, please make sure you add a name so we know
>> >> >> who is coordinating the effort. áIf you don't know who can work
>> >> >> on it, please just post the issue here, and we'll try to find some
>> >> >> help.
>> >> >>
>> >> >> I only know of one issue, which is a noticeable performance degradation
>> >> >> that was reported a while ago:
>> >> >>
>> >> >
>> >> > I'd like to merge x32 into GDB 7.5. áMy x32 change is on hjl/x32/master
>> >> > branch at
>> >> >
>> >> > http://sourceware.org/git/?p=gdb.git;a=summary
>> >> >
>> >> > The current diff only has 864 lines. áOne patch:
>> >> >
>> >> > http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
>> >> >
>> >> > isn't reviewed yet. áI will open a meta bug for x32 integration.
>> >> >
>> >>
>> >> I opened:
>> >>
>> >> http://sourceware.org/bugzilla/show_bug.cgi?id=14099
>> >>
>> >> Thanks for help from everyone. áThe full GDBserver x32 support
>> >> as well as partial GDB x32 support have been checked in. áThe
>> >> remaining patches are:
>> >>
>> >> http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html
>> >> http://sourceware.org/ml/gdb-patches/2012-04/msg00191.html
>> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html
>> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00531.html
>> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00533.html
>> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00489.html
>> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00438.html
>> >> http://sourceware.org/ml/gdb-patches/2012-05/msg00097.html
>> >>
>> >> I would appreciate help to get them reviewed and approved.
>> >
>> > As I wrote before, I don't think adding lots if if-statements is the
>> > proper way to add a new ABI to GDB. áThe proper way is to do it like
>> > the diff below. áIn that diff, I'm not entirely confident that calling
>> > amd64_linux_init_abi() from amd64_x32_linux_init_abi() makes all that
>> > much sense. áFor example the amd64_linux_record_tdep stuff probably
>> > isn't right for the x32 ABI. áBut at least this will give us a
>> > starting point where we won't end up adding
>> >
>> > áif (gdbarch_ptr_bit (gdbarch) == 32)
>> > á á{
>> > á á á...
>> > á á}
>>
>> Please take a look at
>>
>> http://sourceware.org/ml/gdb-patches/2012-04/msg00195.html
>>
>> It doesn't add any  (gdbarch_ptr_bit (gdbarch) == 32).  It just changes
>> it to bits_per_word.  I add one  "gdbarch_ptr_bit (gdbarch) == 32" in
>> amd64_linux_sigtramp_start and I will remove them from
>>
>> http://sourceware.org/ml/gdb-patches/2012-05/msg00744.html
>
> Well, I'm also thining about the future here.  Stuff you haven't
> addressed yet in your diff series and stuff that will be added later.
>
>> > Index: amd64-linux-tdep.c
>> > ===================================================================
>> > RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
>> > retrieving revision 1.50
>> > diff -u -p -r1.50 amd64-linux-tdep.c
>> > --- amd64-linux-tdep.c á12 May 2012 08:54:03 -0000 á á á1.50
>> > +++ amd64-linux-tdep.c á20 May 2012 20:31:53 -0000
>> > @@ -1543,6 +1543,24 @@ amd64_linux_init_abi (struct gdbarch_inf
>> >
>> > á tdep->i386_syscall_record = amd64_linux_syscall_record;
>> > á}
>> > +
>> > +static void
>> > +amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
>> > +{
>> > + ástruct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>> > + áconst struct target_desc *tdesc = info.target_desc;
>> > +
>> > + áamd64_linux_init_abi (info, gdbarch);
>> > + áamd64_x32_init_abi (info, gdbarch);
>> > +
>> > + áif (! tdesc_has_registers (tdesc))
>> > + á átdesc = tdesc_amd64_linux;
>>
>> I assume you meant tdesc_x32_linux here.  The problem is
>> when we reach here, if (! tdesc_has_registers (tdesc)) will always
>> be false since tdep->tdesc has been set by amd64_linux_init_abi.
>>
>> > + átdep->tdesc = tdesc;
>> > +
>> > + á/* GNU/Linux uses SVR4-style shared libraries. á*/
>> > + áset_solib_svr4_fetch_link_map_offsets
>> > + á á(gdbarch, svr4_ilp32_fetch_link_map_offsets);
>> > +}
>> >
>> >
>> > á/* Provide a prototype to silence -Wmissing-prototypes. á*/
>> > @@ -1553,6 +1571,8 @@ _initialize_amd64_linux_tdep (void)
>> > á{
>> > á gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
>> > á á á á á á á á á á á á áGDB_OSABI_LINUX, amd64_linux_init_abi);
>> > + ágdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
>> > + á á á á á á á á á á á á GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
>> >
>> > á /* Initialize the Linux target description. á*/
>> > á initialize_tdesc_amd64_linux ();
>> > Index: amd64-tdep.c
>> > ===================================================================
>> > RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
>> > retrieving revision 1.104
>> > diff -u -p -r1.104 amd64-tdep.c
>> > --- amd64-tdep.c á á á á14 May 2012 18:56:40 -0000 á á á1.104
>> > +++ amd64-tdep.c á á á á20 May 2012 20:31:54 -0000
>> > @@ -258,7 +258,8 @@ static const char *amd64_word_names[] =
>> > ástatic const char *amd64_dword_names[] =
>> > á{
>> > á "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp",
>> > - á"r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
>> > + á"r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
>> > + á"eip"
>> > á};
>> >
>> > á/* Return the name of register REGNUM. á*/
>> > @@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info
>> > á set_gdbarch_stap_parse_special_token (gdbarch,
>> > á á á á á á á á á á á á á á á á á á á ái386_stap_parse_special_token);
>> > á}
>> > +
>> > +
>> > +static struct type *
>> > +amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
>> > +{
>> > + ástruct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>> > +
>> > + áswitch (regnum - tdep->eax_regnum)
>> > + á á{
>> > + á ácase AMD64_RBP_REGNUM: á á /* %ebp */
>> > + á ácase AMD64_RSP_REGNUM: á á /* %esp */
>> > + á á áreturn builtin_type (gdbarch)->builtin_data_ptr;
>> > + á ácase AMD64_RIP_REGNUM: á á /* %eip */
>> > + á á áreturn builtin_type (gdbarch)->builtin_func_ptr;
>> > + á á}
>> > +
>> > + áreturn i386_pseudo_register_type (gdbarch, regnum);
>> > +}
>> > +
>> > +void
>> > +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>> > +{
>> > + ástruct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>> > + áconst struct target_desc *tdesc = info.target_desc;
>> > +
>> > + áamd64_init_abi (info, gdbarch);
>> > +
>> > + áif (! tdesc_has_registers (tdesc))
>> > + á átdesc = tdesc_x32;
>>
>> Again, " if (! tdesc_has_registers (tdesc))" will always false
>> since tdep->tdesc has been set in amd64_init_abi.
>
> I don't think that's true.  Here tdesc comes from info.target_desc,
> not tdep->tdesc, so the check should still do the right thing.  In
> fact it must do the right thing, since amd64_linux_init_abi() does the
> same thing already.

Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
since amd64_x32_linux_init_abi can't call amd64_init_abi after
calling amd64_linux_init_abi.

Thanks.

-- 
H.J.
---
2012-05-20  Mark Kettenis  <kettenis@gnu.org>
	    H.J. Lu  <hongjiu.lu@intel.com>

	* amd64-linux-tdep.c (amd64_x32_linux_init_abi): New functiom.
	(_initialize_amd64_linux_tdep): Register bfd_mach_x64_32 with
	amd64_x32_linux_init_abi.

	* amd64-tdep.c (amd64_x32_pseudo_register_type): New function.
	(amd64_x32_pseudo_register_name): Likewise.
	(x32_init_abi): Likewise.
	(amd64_x32_init_abi): Likewise.

	* amd64-tdep.h (amd64_x32_init_abi): New prototype.
	(x32_init_abi): Likewise.

	* i386-tdep.c (i386_pseudo_register_type): Make it global.
	(i386_gdbarch_init): Initialize sp_regnum_from_eax and
	pc_regnum_from_eax to -1.  Update SP regnum from
	sp_regnum_from_eax and PC regnum from pc_regnum_from_eax if
	needed.

	* i386-tdep.h (gdbarch_tdep): Add sp_regnum_from_eax and
	pc_regnum_from_eax.
	(i386_pseudo_register_type): New prototype.

diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c
index 22a3464..470680d 100644
--- a/gdb/amd64-linux-tdep.c
+++ b/gdb/amd64-linux-tdep.c
@@ -1543,6 +1558,26 @@ amd64_linux_init_abi (struct gdbarch_info info,
struct gdbarch *gdbarch)

   tdep->i386_syscall_record = amd64_linux_syscall_record;
 }
+
+static void
+amd64_x32_linux_init_abi (struct gdbarch_info info,
+			   struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+
+  amd64_linux_init_abi (info, gdbarch);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_amd64_linux;
+  tdep->tdesc = tdesc;
+
+  x32_init_abi (gdbarch);
+
+   /* GNU/Linux uses SVR4-style shared libraries.  */
+  set_solib_svr4_fetch_link_map_offsets
+    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
+}



 /* Provide a prototype to silence -Wmissing-prototypes.  */
@@ -1553,6 +1588,8 @@ _initialize_amd64_linux_tdep (void)
 {
   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
 			  GDB_OSABI_LINUX, amd64_linux_init_abi);
+  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
+			  GDB_OSABI_LINUX, amd64_x32_linux_init_abi);

   /* Initialize the Linux target description.  */
   initialize_tdesc_amd64_linux ();
diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
index df91a51..efa9f5e 100644
--- a/gdb/amd64-tdep.c
+++ b/gdb/amd64-tdep.c
@@ -261,6 +261,28 @@ static const char *amd64_dword_names[] =
   "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
 };

+/* Return the GDB type object for the "standard" data type of data in
+   register REGNUM.  Only used for x32.  */
+
+static struct type *
+amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
+{
+  /* Use pointer types for ebp, esp and eip registers in x32.  */
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  switch (regnum - tdep->eax_regnum)
+    {
+    default:
+      break;
+    case AMD64_RBP_REGNUM:	/* ebp  */
+    case AMD64_RSP_REGNUM:	/* esp	*/
+      return builtin_type (gdbarch)->builtin_data_ptr;
+    case AMD64_RIP_REGNUM:	/* eip */
+      return builtin_type (gdbarch)->builtin_func_ptr;
+    }
+
+  return i386_pseudo_register_type (gdbarch, regnum);
+}
+
 /* Return the name of register REGNUM.  */

 static const char *
@@ -279,6 +301,17 @@ amd64_pseudo_register_name (struct gdbarch
*gdbarch, int regnum)
     return i386_pseudo_register_name (gdbarch, regnum);
 }

+/* Return the name of register REGNUM.  Only used for x32.  */
+
+static const char *
+amd64_x32_pseudo_register_name (struct gdbarch *gdbarch, int regnum)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  if ((regnum - tdep->eax_regnum) == AMD64_RIP_REGNUM)
+    return "eip";
+  return amd64_pseudo_register_name (gdbarch, regnum);
+}
+
 static struct value *
 amd64_pseudo_register_read_value (struct gdbarch *gdbarch,
 				  struct regcache *regcache,
@@ -2730,6 +2803,37 @@ amd64_init_abi (struct gdbarch_info info,
struct gdbarch *gdbarch)
 					i386_stap_parse_special_token);
 }

+void
+x32_init_abi (struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  tdep->num_dword_regs = 17;
+  tdep->sp_regnum_from_eax = AMD64_RSP_REGNUM;
+  tdep->pc_regnum_from_eax = AMD64_RIP_REGNUM;
+
+  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
+  set_tdesc_pseudo_register_name (gdbarch, amd64_x32_pseudo_register_name);
+
+  set_gdbarch_long_bit (gdbarch, 32);
+  set_gdbarch_ptr_bit (gdbarch, 32);
+}
+
+void
+amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+
+  amd64_init_abi (info, gdbarch);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_x32;
+  tdep->tdesc = tdesc;
+
+  x32_init_abi (gdbarch);
+}
+
 /* Provide a prototype to silence -Wmissing-prototypes.  */
 void _initialize_amd64_tdep (void);

diff --git a/gdb/amd64-tdep.h b/gdb/amd64-tdep.h
index 1ed109c..401b379 100644
--- a/gdb/amd64-tdep.h
+++ b/gdb/amd64-tdep.h
@@ -80,6 +80,9 @@ extern void amd64_displaced_step_fixup (struct
gdbarch *gdbarch,
 					struct regcache *regs);

 extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
+extern void amd64_x32_init_abi (struct gdbarch_info info,
+				struct gdbarch *gdbarch);
+extern void x32_init_abi (struct gdbarch *gdbarch);

 /* Fill register REGNUM in REGCACHE with the appropriate
    floating-point or SSE register value from *FXSAVE.  If REGNUM is
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 5b04505..9cc2e30 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -2780,7 +2780,7 @@ i386_mmx_type (struct gdbarch *gdbarch)
 /* Return the GDB type object for the "standard" data type of data in
    register REGNUM.  */

-static struct type *
+struct type *
 i386_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
 {
   if (i386_mmx_regnum_p (gdbarch, regnum))
@@ -7787,6 +7787,9 @@ i386_gdbarch_init (struct gdbarch_info info,
struct gdbarch_list *arches)
   tdep->num_mmx_regs = 8;
   tdep->num_ymm_regs = 0;

+  tdep->sp_regnum_from_eax = -1;
+  tdep->pc_regnum_from_eax = -1;
+
   tdesc_data = tdesc_data_alloc ();

   set_gdbarch_relocate_instruction (gdbarch, i386_relocate_instruction);
@@ -7831,6 +7834,14 @@ i386_gdbarch_init (struct gdbarch_info info,
struct gdbarch_list *arches)
       /* Support dword pseudo-register if it hasn't been disabled.  */
       tdep->eax_regnum = ymm0_regnum;
       ymm0_regnum += tdep->num_dword_regs;
+      if (tdep->sp_regnum_from_eax != -1)
+	set_gdbarch_sp_regnum (gdbarch,
+			       (tdep->eax_regnum
+				+ tdep->sp_regnum_from_eax));
+      if (tdep->pc_regnum_from_eax != -1)
+	set_gdbarch_pc_regnum (gdbarch,
+			       (tdep->eax_regnum
+				+ tdep->pc_regnum_from_eax));
     }
   else
     tdep->eax_regnum = -1;
diff --git a/gdb/i386-tdep.h b/gdb/i386-tdep.h
index f297ae7..e1f7c44 100644
--- a/gdb/i386-tdep.h
+++ b/gdb/i386-tdep.h
@@ -149,6 +149,14 @@ struct gdbarch_tdep
      of pseudo dword register support.  */
   int eax_regnum;

+  /* Register number for SP, relative to %eax.  Set this to -1 to
+     indicate the absence of pseudo SP register support.  */
+  int sp_regnum_from_eax;
+
+  /* Register number for PC, relative to %eax.  Set this to -1 to
+     indicate the absence of pseudo PC register support.  */
+  int pc_regnum_from_eax;
+
   /* Number of core registers.  */
   int num_core_regs;

@@ -307,6 +315,7 @@ extern int i386_dword_regnum_p (struct gdbarch
*gdbarch, int regnum);
 extern int i386_xmm_regnum_p (struct gdbarch *gdbarch, int regnum);
 extern int i386_ymm_regnum_p (struct gdbarch *gdbarch, int regnum);

+extern struct type *i386_pseudo_register_type (struct gdbarch *, int);
 extern const char *i386_pseudo_register_name (struct gdbarch *gdbarch,
 					      int regnum);


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-20 22:49           ` H.J. Lu
@ 2012-05-25 16:52             ` H.J. Lu
  2012-05-28 20:26             ` x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release)) Mark Kettenis
  1 sibling, 0 replies; 42+ messages in thread
From: H.J. Lu @ 2012-05-25 16:52 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: brobecker, gdb-patches

On Sun, May 20, 2012 at 3:48 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> I don't think that's true.  Here tdesc comes from info.target_desc,
>> not tdep->tdesc, so the check should still do the right thing.  In
>> fact it must do the right thing, since amd64_linux_init_abi() does the
>> same thing already.
>
> Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
> since amd64_x32_linux_init_abi can't call amd64_init_abi after
> calling amd64_linux_init_abi.
>
> Thanks.

Hi Mark,

Can you take a look at this?

Thanks.

H.J.
> --
> H.J.
> ---
> 2012-05-20  Mark Kettenis  <kettenis@gnu.org>
>            H.J. Lu  <hongjiu.lu@intel.com>
>
>        * amd64-linux-tdep.c (amd64_x32_linux_init_abi): New functiom.
>        (_initialize_amd64_linux_tdep): Register bfd_mach_x64_32 with
>        amd64_x32_linux_init_abi.
>
>        * amd64-tdep.c (amd64_x32_pseudo_register_type): New function.
>        (amd64_x32_pseudo_register_name): Likewise.
>        (x32_init_abi): Likewise.
>        (amd64_x32_init_abi): Likewise.
>
>        * amd64-tdep.h (amd64_x32_init_abi): New prototype.
>        (x32_init_abi): Likewise.
>
>        * i386-tdep.c (i386_pseudo_register_type): Make it global.
>        (i386_gdbarch_init): Initialize sp_regnum_from_eax and
>        pc_regnum_from_eax to -1.  Update SP regnum from
>        sp_regnum_from_eax and PC regnum from pc_regnum_from_eax if
>        needed.
>
>        * i386-tdep.h (gdbarch_tdep): Add sp_regnum_from_eax and
>        pc_regnum_from_eax.
>        (i386_pseudo_register_type): New prototype.
>
> diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c
> index 22a3464..470680d 100644
> --- a/gdb/amd64-linux-tdep.c
> +++ b/gdb/amd64-linux-tdep.c
> @@ -1543,6 +1558,26 @@ amd64_linux_init_abi (struct gdbarch_info info,
> struct gdbarch *gdbarch)
>
>   tdep->i386_syscall_record = amd64_linux_syscall_record;
>  }
> +
> +static void
> +amd64_x32_linux_init_abi (struct gdbarch_info info,
> +                          struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +
> +  amd64_linux_init_abi (info, gdbarch);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_amd64_linux;
> +  tdep->tdesc = tdesc;
> +
> +  x32_init_abi (gdbarch);
> +
> +   /* GNU/Linux uses SVR4-style shared libraries.  */
> +  set_solib_svr4_fetch_link_map_offsets
> +    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
> +}
>
>
>
>  /* Provide a prototype to silence -Wmissing-prototypes.  */
> @@ -1553,6 +1588,8 @@ _initialize_amd64_linux_tdep (void)
>  {
>   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
>                          GDB_OSABI_LINUX, amd64_linux_init_abi);
> +  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
> +                         GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
>
>   /* Initialize the Linux target description.  */
>   initialize_tdesc_amd64_linux ();
> diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
> index df91a51..efa9f5e 100644
> --- a/gdb/amd64-tdep.c
> +++ b/gdb/amd64-tdep.c
> @@ -261,6 +261,28 @@ static const char *amd64_dword_names[] =
>   "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
>  };
>
> +/* Return the GDB type object for the "standard" data type of data in
> +   register REGNUM.  Only used for x32.  */
> +
> +static struct type *
> +amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
> +{
> +  /* Use pointer types for ebp, esp and eip registers in x32.  */
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  switch (regnum - tdep->eax_regnum)
> +    {
> +    default:
> +      break;
> +    case AMD64_RBP_REGNUM:     /* ebp  */
> +    case AMD64_RSP_REGNUM:     /* esp  */
> +      return builtin_type (gdbarch)->builtin_data_ptr;
> +    case AMD64_RIP_REGNUM:     /* eip */
> +      return builtin_type (gdbarch)->builtin_func_ptr;
> +    }
> +
> +  return i386_pseudo_register_type (gdbarch, regnum);
> +}
> +
>  /* Return the name of register REGNUM.  */
>
>  static const char *
> @@ -279,6 +301,17 @@ amd64_pseudo_register_name (struct gdbarch
> *gdbarch, int regnum)
>     return i386_pseudo_register_name (gdbarch, regnum);
>  }
>
> +/* Return the name of register REGNUM.  Only used for x32.  */
> +
> +static const char *
> +amd64_x32_pseudo_register_name (struct gdbarch *gdbarch, int regnum)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  if ((regnum - tdep->eax_regnum) == AMD64_RIP_REGNUM)
> +    return "eip";
> +  return amd64_pseudo_register_name (gdbarch, regnum);
> +}
> +
>  static struct value *
>  amd64_pseudo_register_read_value (struct gdbarch *gdbarch,
>                                  struct regcache *regcache,
> @@ -2730,6 +2803,37 @@ amd64_init_abi (struct gdbarch_info info,
> struct gdbarch *gdbarch)
>                                        i386_stap_parse_special_token);
>  }
>
> +void
> +x32_init_abi (struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +
> +  tdep->num_dword_regs = 17;
> +  tdep->sp_regnum_from_eax = AMD64_RSP_REGNUM;
> +  tdep->pc_regnum_from_eax = AMD64_RIP_REGNUM;
> +
> +  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
> +  set_tdesc_pseudo_register_name (gdbarch, amd64_x32_pseudo_register_name);
> +
> +  set_gdbarch_long_bit (gdbarch, 32);
> +  set_gdbarch_ptr_bit (gdbarch, 32);
> +}
> +
> +void
> +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +
> +  amd64_init_abi (info, gdbarch);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_x32;
> +  tdep->tdesc = tdesc;
> +
> +  x32_init_abi (gdbarch);
> +}
> +
>  /* Provide a prototype to silence -Wmissing-prototypes.  */
>  void _initialize_amd64_tdep (void);
>
> diff --git a/gdb/amd64-tdep.h b/gdb/amd64-tdep.h
> index 1ed109c..401b379 100644
> --- a/gdb/amd64-tdep.h
> +++ b/gdb/amd64-tdep.h
> @@ -80,6 +80,9 @@ extern void amd64_displaced_step_fixup (struct
> gdbarch *gdbarch,
>                                        struct regcache *regs);
>
>  extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
> +extern void amd64_x32_init_abi (struct gdbarch_info info,
> +                               struct gdbarch *gdbarch);
> +extern void x32_init_abi (struct gdbarch *gdbarch);
>
>  /* Fill register REGNUM in REGCACHE with the appropriate
>    floating-point or SSE register value from *FXSAVE.  If REGNUM is
> diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
> index 5b04505..9cc2e30 100644
> --- a/gdb/i386-tdep.c
> +++ b/gdb/i386-tdep.c
> @@ -2780,7 +2780,7 @@ i386_mmx_type (struct gdbarch *gdbarch)
>  /* Return the GDB type object for the "standard" data type of data in
>    register REGNUM.  */
>
> -static struct type *
> +struct type *
>  i386_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
>  {
>   if (i386_mmx_regnum_p (gdbarch, regnum))
> @@ -7787,6 +7787,9 @@ i386_gdbarch_init (struct gdbarch_info info,
> struct gdbarch_list *arches)
>   tdep->num_mmx_regs = 8;
>   tdep->num_ymm_regs = 0;
>
> +  tdep->sp_regnum_from_eax = -1;
> +  tdep->pc_regnum_from_eax = -1;
> +
>   tdesc_data = tdesc_data_alloc ();
>
>   set_gdbarch_relocate_instruction (gdbarch, i386_relocate_instruction);
> @@ -7831,6 +7834,14 @@ i386_gdbarch_init (struct gdbarch_info info,
> struct gdbarch_list *arches)
>       /* Support dword pseudo-register if it hasn't been disabled.  */
>       tdep->eax_regnum = ymm0_regnum;
>       ymm0_regnum += tdep->num_dword_regs;
> +      if (tdep->sp_regnum_from_eax != -1)
> +       set_gdbarch_sp_regnum (gdbarch,
> +                              (tdep->eax_regnum
> +                               + tdep->sp_regnum_from_eax));
> +      if (tdep->pc_regnum_from_eax != -1)
> +       set_gdbarch_pc_regnum (gdbarch,
> +                              (tdep->eax_regnum
> +                               + tdep->pc_regnum_from_eax));
>     }
>   else
>     tdep->eax_regnum = -1;
> diff --git a/gdb/i386-tdep.h b/gdb/i386-tdep.h
> index f297ae7..e1f7c44 100644
> --- a/gdb/i386-tdep.h
> +++ b/gdb/i386-tdep.h
> @@ -149,6 +149,14 @@ struct gdbarch_tdep
>      of pseudo dword register support.  */
>   int eax_regnum;
>
> +  /* Register number for SP, relative to %eax.  Set this to -1 to
> +     indicate the absence of pseudo SP register support.  */
> +  int sp_regnum_from_eax;
> +
> +  /* Register number for PC, relative to %eax.  Set this to -1 to
> +     indicate the absence of pseudo PC register support.  */
> +  int pc_regnum_from_eax;
> +
>   /* Number of core registers.  */
>   int num_core_regs;
>
> @@ -307,6 +315,7 @@ extern int i386_dword_regnum_p (struct gdbarch
> *gdbarch, int regnum);
>  extern int i386_xmm_regnum_p (struct gdbarch *gdbarch, int regnum);
>  extern int i386_ymm_regnum_p (struct gdbarch *gdbarch, int regnum);
>
> +extern struct type *i386_pseudo_register_type (struct gdbarch *, int);
>  extern const char *i386_pseudo_register_name (struct gdbarch *gdbarch,
>                                              int regnum);



-- 
H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-05-20 22:49           ` H.J. Lu
  2012-05-25 16:52             ` H.J. Lu
@ 2012-05-28 20:26             ` Mark Kettenis
  2012-05-28 21:18               ` H.J. Lu
  1 sibling, 1 reply; 42+ messages in thread
From: Mark Kettenis @ 2012-05-28 20:26 UTC (permalink / raw)
  To: hjl.tools; +Cc: gdb-patches

> Date: Sun, 20 May 2012 15:48:54 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
> since amd64_x32_linux_init_abi can't call amd64_init_abi after
> calling amd64_linux_init_abi.

I guess multiple-inheritance is a bad idea, even when implemented in C ;)

I really do think that amd64_x32_linux_init_abi() should call
amd64_x32_init_abi().  That way it is immediately obvious that the OS-specific ABI inherits everything from the generic ABI.

In order too avoid too much code duplication, the common bits should
be split out from amd64_linux_init_abi() into a seperate function that
gets called from both amd64_linux_init_abi() and
amd64_x32_linux_init_abi().  As I wrote earlier, it isn't entirely
obvious that everything in amd64_linix_init_abi() applies to the x32
ABI.  So we should be conservative in moving stuff into the common
function.  In fact it might be a good idea to start out with something
like the attached diff, and gradually move things over.

Cheers,

Mark

Index: amd64-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
retrieving revision 1.50
diff -u -p -r1.50 amd64-linux-tdep.c
--- amd64-linux-tdep.c	12 May 2012 08:54:03 -0000	1.50
+++ amd64-linux-tdep.c	28 May 2012 20:24:28 -0000
@@ -1298,8 +1298,6 @@ amd64_linux_init_abi (struct gdbarch_inf
 
   gdb_assert (tdesc_data);
 
-  linux_init_abi (info, gdbarch);
-
   tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
   tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
   tdep->sizeof_gregset = 27 * 8;
@@ -1323,6 +1321,8 @@ amd64_linux_init_abi (struct gdbarch_inf
   if (!valid_p)
     return;
 
+  linux_init_abi (info, gdbarch);
+
   tdep->sigtramp_p = amd64_linux_sigtramp_p;
   tdep->sigcontext_addr = amd64_linux_sigcontext_addr;
   tdep->sc_reg_offset = amd64_linux_sc_reg_offset;
@@ -1543,6 +1543,44 @@ amd64_linux_init_abi (struct gdbarch_inf
 
   tdep->i386_syscall_record = amd64_linux_syscall_record;
 }
+
+static void
+amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+
+  gdb_assert (tdesc_data);
+
+  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
+  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
+  tdep->sizeof_gregset = 27 * 8;
+
+  amd64_x32_init_abi (info, gdbarch);
+
+  /* Reserve a number for orig_rax.  */
+  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_x32_linux;
+  tdep->tdesc = tdesc;
+
+  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
+  if (feature == NULL)
+    return;
+
+  valid_p = tdesc_numbered_register (feature, tdesc_data,
+				     AMD64_LINUX_ORIG_RAX_REGNUM,
+				     "orig_rax");
+  if (!valid_p)
+    return;
+
+  linux_init_abi (info, gdbarch);
+
+  /* GNU/Linux uses SVR4-style shared libraries.  */
+  set_solib_svr4_fetch_link_map_offsets
+    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
+}
 \f
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
@@ -1553,6 +1591,8 @@ _initialize_amd64_linux_tdep (void)
 {
   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
 			  GDB_OSABI_LINUX, amd64_linux_init_abi);
+  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
+			  GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
 
   /* Initialize the Linux target description.  */
   initialize_tdesc_amd64_linux ();
Index: amd64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
retrieving revision 1.104
diff -u -p -r1.104 amd64-tdep.c
--- amd64-tdep.c	14 May 2012 18:56:40 -0000	1.104
+++ amd64-tdep.c	28 May 2012 20:24:29 -0000
@@ -258,7 +258,8 @@ static const char *amd64_word_names[] =
 static const char *amd64_dword_names[] =
 {
   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp", 
-  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
+  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
+  "eip"
 };
 
 /* Return the name of register REGNUM.  */
@@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info
   set_gdbarch_stap_parse_special_token (gdbarch,
 					i386_stap_parse_special_token);
 }
+\f
+
+static struct type *
+amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  switch (regnum - tdep->eax_regnum)
+    {
+    case AMD64_RBP_REGNUM:	/* %ebp */
+    case AMD64_RSP_REGNUM:	/* %esp */
+      return builtin_type (gdbarch)->builtin_data_ptr;
+    case AMD64_RIP_REGNUM:	/* %eip */
+      return builtin_type (gdbarch)->builtin_func_ptr;
+    }
+
+  return i386_pseudo_register_type (gdbarch, regnum);
+}
+
+void
+amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+
+  amd64_init_abi (info, gdbarch);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_x32;
+  tdep->tdesc = tdesc;
+
+  tdep->num_dword_regs = 17;
+  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
+
+  set_gdbarch_long_bit (gdbarch, 32);
+  set_gdbarch_ptr_bit (gdbarch, 32);
+}
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
 void _initialize_amd64_tdep (void);
Index: amd64-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.h,v
retrieving revision 1.21
diff -u -p -r1.21 amd64-tdep.h
--- amd64-tdep.h	4 Jan 2012 08:16:56 -0000	1.21
+++ amd64-tdep.h	28 May 2012 20:24:29 -0000
@@ -80,6 +80,8 @@ extern void amd64_displaced_step_fixup (
 					struct regcache *regs);
 
 extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
+extern void amd64_x32_init_abi (struct gdbarch_info info,
+				struct gdbarch *gdbarch);
 
 /* Fill register REGNUM in REGCACHE with the appropriate
    floating-point or SSE register value from *FXSAVE.  If REGNUM is


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-05-28 20:26             ` x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release)) Mark Kettenis
@ 2012-05-28 21:18               ` H.J. Lu
  2012-05-31 18:18                 ` H.J. Lu
  0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2012-05-28 21:18 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

On Mon, May 28, 2012 at 1:26 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Sun, 20 May 2012 15:48:54 -0700
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>
>> Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
>> since amd64_x32_linux_init_abi can't call amd64_init_abi after
>> calling amd64_linux_init_abi.
>
> I guess multiple-inheritance is a bad idea, even when implemented in C ;)
>
> I really do think that amd64_x32_linux_init_abi() should call
> amd64_x32_init_abi().  That way it is immediately obvious that the OS-specific ABI inherits everything from the generic ABI.

X32 kernel interface are highly OS specific.  Different OSes can implement
very different kernel interfaces.  The only generic x32 bits are

  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);

  tdep->num_dword_regs = 17;

  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);

  set_gdbarch_long_bit (gdbarch, 32);
  set_gdbarch_ptr_bit (gdbarch, 32);

They are the same for all x32 OSes since they are determined by
hardware, not OS.

> In order too avoid too much code duplication, the common bits should
> be split out from amd64_linux_init_abi() into a seperate function that
> gets called from both amd64_linux_init_abi() and
> amd64_x32_linux_init_abi().  As I wrote earlier, it isn't entirely
> obvious that everything in amd64_linix_init_abi() applies to the x32
> ABI.  So we should be conservative in moving stuff into the common
> function.  In fact it might be a good idea to start out with something
> like the attached diff, and gradually move things over.

Linux x32 kernel interface shares > 90% of Linux amd64 kernel
interface (309 system calls out of 337 are the same).  See
64-bit system call table in Linux kernel 3.4:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=arch/x86/syscalls/syscall_64.tbl;h=dd29a9ea27c560a9d2fcb6e1c2983f8b8e9be407;hb=HEAD

I believe we should start with sharing everything between Linux/x32
and Linux/amd64.  We can update x32 part as we go.

> Cheers,
>
> Mark
>
> Index: amd64-linux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 amd64-linux-tdep.c
> --- amd64-linux-tdep.c  12 May 2012 08:54:03 -0000      1.50
> +++ amd64-linux-tdep.c  28 May 2012 20:24:28 -0000
> @@ -1298,8 +1298,6 @@ amd64_linux_init_abi (struct gdbarch_inf
>
>   gdb_assert (tdesc_data);
>
> -  linux_init_abi (info, gdbarch);
> -
>   tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
>   tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
>   tdep->sizeof_gregset = 27 * 8;
> @@ -1323,6 +1321,8 @@ amd64_linux_init_abi (struct gdbarch_inf
>   if (!valid_p)
>     return;
>
> +  linux_init_abi (info, gdbarch);
> +
>   tdep->sigtramp_p = amd64_linux_sigtramp_p;
>   tdep->sigcontext_addr = amd64_linux_sigcontext_addr;
>   tdep->sc_reg_offset = amd64_linux_sc_reg_offset;
> @@ -1543,6 +1543,44 @@ amd64_linux_init_abi (struct gdbarch_inf
>
>   tdep->i386_syscall_record = amd64_linux_syscall_record;
>  }
> +
> +static void
> +amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +
> +  gdb_assert (tdesc_data);
> +
> +  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
> +  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
> +  tdep->sizeof_gregset = 27 * 8;
> +
> +  amd64_x32_init_abi (info, gdbarch);
> +
> +  /* Reserve a number for orig_rax.  */
> +  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_x32_linux;
> +  tdep->tdesc = tdesc;
> +
> +  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
> +  if (feature == NULL)
> +    return;
> +
> +  valid_p = tdesc_numbered_register (feature, tdesc_data,
> +                                    AMD64_LINUX_ORIG_RAX_REGNUM,
> +                                    "orig_rax");
> +  if (!valid_p)
> +    return;
> +
> +  linux_init_abi (info, gdbarch);
> +
> +  /* GNU/Linux uses SVR4-style shared libraries.  */
> +  set_solib_svr4_fetch_link_map_offsets
> +    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
> +}

These won't work for x32.  We have to copy almost everything in
amd64_linux_init_abi.

> +void
> +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +
> +  amd64_init_abi (info, gdbarch);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_x32;
> +  tdep->tdesc = tdesc;
> +
> +  tdep->num_dword_regs = 17;
> +  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
> +
> +  set_gdbarch_long_bit (gdbarch, 32);
> +  set_gdbarch_ptr_bit (gdbarch, 32);
> +}
>

I think this is the wrong approach for x32 support. We should
break amd64_x32_init_abi into 2 parts:

1. OS specific part.  It should be private to amd64-tdep.c.
2. Generic part.  It should be exported from amd64-tdep.c and can
be used by all x32 OSes.

Thanks.


-- 
H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-11 18:17 Three weeks to branching (gdb 7.5 release) Joel Brobecker
  2012-05-11 18:43 ` H.J. Lu
  2012-05-12 15:26 ` Three weeks to branching (gdb 7.5 release) Doug Evans
@ 2012-05-29 17:17 ` Jan Kratochvil
  2012-05-30 22:04   ` Joel Brobecker
  2 siblings, 1 reply; 42+ messages in thread
From: Jan Kratochvil @ 2012-05-29 17:17 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

On Fri, 11 May 2012 20:17:37 +0200, Joel Brobecker wrote:
>     http://sourceware.org/gdb/wiki/GDB_7.5_Release
> 
> When you add an issue,

[Jan] Fix gdb.cp/gdb2495.exp regression with gcc-4.7
    http://sourceware.org/ml/gdb-patches/2012-03/msg00357.html 1/2
    http://sourceware.org/ml/gdb-patches/2012-03/msg00358.html 2/2 
 - This is not a regression of GDB itself but it is a regression of the whole
   GNU toolchain.  There is missing some protection against stale breakpoints
   on stack (ON_STACK) after longjmps/throws (I do not remember it much now).
   I use in Fedora these patches.

[Jan] workaround stale frame_info * ( http://sourceware.org/bugzilla/show_bug.cgi?id=13866 )
    http://sourceware.org/ml/gdb-patches/2012-04/msg00058.html 
 - some proper fix will almost sure not get into 7.5 so maybe to fix "finish"
   crashes the workaround could be even applied for FSF GDB HEAD?
   I use in Fedora this workaround.


Regards,
Jan


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-29 17:17 ` Three weeks to branching (gdb 7.5 release) Jan Kratochvil
@ 2012-05-30 22:04   ` Joel Brobecker
  2012-06-07 19:36     ` Maciej W. Rozycki
  0 siblings, 1 reply; 42+ messages in thread
From: Joel Brobecker @ 2012-05-30 22:04 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: gdb-patches

> [Jan] Fix gdb.cp/gdb2495.exp regression with gcc-4.7
>     http://sourceware.org/ml/gdb-patches/2012-03/msg00357.html 1/2
>     http://sourceware.org/ml/gdb-patches/2012-03/msg00358.html 2/2 
>  - This is not a regression of GDB itself but it is a regression of the whole
>    GNU toolchain.  There is missing some protection against stale breakpoints
>    on stack (ON_STACK) after longjmps/throws (I do not remember it much now).
>    I use in Fedora these patches.
> 
> [Jan] workaround stale frame_info * ( http://sourceware.org/bugzilla/show_bug.cgi?id=13866 )
>     http://sourceware.org/ml/gdb-patches/2012-04/msg00058.html 
>  - some proper fix will almost sure not get into 7.5 so maybe to fix "finish"
>    crashes the workaround could be even applied for FSF GDB HEAD?
>    I use in Fedora this workaround.

Thanks for the heads up, Jan. Looks like me might want to delay
the branch. I can't remember that Doug said he was done on his end.

There is no real hurry until the end of the month. After that,
my schedule gets really tight again, pretty much until mid-september.
I still expect to be able to make the branch, and possibly produce
the release, but I might not be able to push for regular updates
the way I like to do...

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-05-28 21:18               ` H.J. Lu
@ 2012-05-31 18:18                 ` H.J. Lu
  2012-06-05 12:58                   ` H.J. Lu
  2012-06-10 21:52                   ` Mark Kettenis
  0 siblings, 2 replies; 42+ messages in thread
From: H.J. Lu @ 2012-05-31 18:18 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

On Mon, May 28, 2012 at 2:18 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, May 28, 2012 at 1:26 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>>> Date: Sun, 20 May 2012 15:48:54 -0700
>>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>>
>>> Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
>>> since amd64_x32_linux_init_abi can't call amd64_init_abi after
>>> calling amd64_linux_init_abi.
>>
>> I guess multiple-inheritance is a bad idea, even when implemented in C ;)
>>
>> I really do think that amd64_x32_linux_init_abi() should call
>> amd64_x32_init_abi().  That way it is immediately obvious that the OS-specific ABI inherits everything from the generic ABI.
>
> X32 kernel interface are highly OS specific.  Different OSes can implement
> very different kernel interfaces.  The only generic x32 bits are
>
>  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>
>  tdep->num_dword_regs = 17;
>
>  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
>
>  set_gdbarch_long_bit (gdbarch, 32);
>  set_gdbarch_ptr_bit (gdbarch, 32);
>
> They are the same for all x32 OSes since they are determined by
> hardware, not OS.
>
>> In order too avoid too much code duplication, the common bits should
>> be split out from amd64_linux_init_abi() into a seperate function that
>> gets called from both amd64_linux_init_abi() and
>> amd64_x32_linux_init_abi().  As I wrote earlier, it isn't entirely
>> obvious that everything in amd64_linix_init_abi() applies to the x32
>> ABI.  So we should be conservative in moving stuff into the common
>> function.  In fact it might be a good idea to start out with something
>> like the attached diff, and gradually move things over.
>
> Linux x32 kernel interface shares > 90% of Linux amd64 kernel
> interface (309 system calls out of 337 are the same).  See
> 64-bit system call table in Linux kernel 3.4:
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=arch/x86/syscalls/syscall_64.tbl;h=dd29a9ea27c560a9d2fcb6e1c2983f8b8e9be407;hb=HEAD
>
> I believe we should start with sharing everything between Linux/x32
> and Linux/amd64.  We can update x32 part as we go.
>
>> Cheers,
>>
>> Mark
>>
>> Index: amd64-linux-tdep.c
>> ===================================================================
>> RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
>> retrieving revision 1.50
>> diff -u -p -r1.50 amd64-linux-tdep.c
>> --- amd64-linux-tdep.c  12 May 2012 08:54:03 -0000      1.50
>> +++ amd64-linux-tdep.c  28 May 2012 20:24:28 -0000
>> @@ -1298,8 +1298,6 @@ amd64_linux_init_abi (struct gdbarch_inf
>>
>>   gdb_assert (tdesc_data);
>>
>> -  linux_init_abi (info, gdbarch);
>> -
>>   tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
>>   tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
>>   tdep->sizeof_gregset = 27 * 8;
>> @@ -1323,6 +1321,8 @@ amd64_linux_init_abi (struct gdbarch_inf
>>   if (!valid_p)
>>     return;
>>
>> +  linux_init_abi (info, gdbarch);
>> +
>>   tdep->sigtramp_p = amd64_linux_sigtramp_p;
>>   tdep->sigcontext_addr = amd64_linux_sigcontext_addr;
>>   tdep->sc_reg_offset = amd64_linux_sc_reg_offset;
>> @@ -1543,6 +1543,44 @@ amd64_linux_init_abi (struct gdbarch_inf
>>
>>   tdep->i386_syscall_record = amd64_linux_syscall_record;
>>  }
>> +
>> +static void
>> +amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
>> +{
>> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>> +  const struct target_desc *tdesc = info.target_desc;
>> +
>> +  gdb_assert (tdesc_data);
>> +
>> +  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
>> +  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
>> +  tdep->sizeof_gregset = 27 * 8;
>> +
>> +  amd64_x32_init_abi (info, gdbarch);
>> +
>> +  /* Reserve a number for orig_rax.  */
>> +  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
>> +
>> +  if (! tdesc_has_registers (tdesc))
>> +    tdesc = tdesc_x32_linux;
>> +  tdep->tdesc = tdesc;
>> +
>> +  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
>> +  if (feature == NULL)
>> +    return;
>> +
>> +  valid_p = tdesc_numbered_register (feature, tdesc_data,
>> +                                    AMD64_LINUX_ORIG_RAX_REGNUM,
>> +                                    "orig_rax");
>> +  if (!valid_p)
>> +    return;
>> +
>> +  linux_init_abi (info, gdbarch);
>> +
>> +  /* GNU/Linux uses SVR4-style shared libraries.  */
>> +  set_solib_svr4_fetch_link_map_offsets
>> +    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
>> +}
>
> These won't work for x32.  We have to copy almost everything in
> amd64_linux_init_abi.
>
>> +void
>> +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>> +{
>> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>> +  const struct target_desc *tdesc = info.target_desc;
>> +
>> +  amd64_init_abi (info, gdbarch);
>> +
>> +  if (! tdesc_has_registers (tdesc))
>> +    tdesc = tdesc_x32;
>> +  tdep->tdesc = tdesc;
>> +
>> +  tdep->num_dword_regs = 17;
>> +  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
>> +
>> +  set_gdbarch_long_bit (gdbarch, 32);
>> +  set_gdbarch_ptr_bit (gdbarch, 32);
>> +}
>>
>
> I think this is the wrong approach for x32 support. We should
> break amd64_x32_init_abi into 2 parts:
>
> 1. OS specific part.  It should be private to amd64-tdep.c.
> 2. Generic part.  It should be exported from amd64-tdep.c and can
> be used by all x32 OSes.
>
> Thanks.
>
>

Here is the updated patch.  I added amd64_x32_init for generic x32
setting.  It can be used by all x32 init_abi functions.  Since
tdep->tdesc can't be changed after being used, I renamed
amd64_init_abi/amd64_init_abi to amd64_init/amd64_linux_init
to take an  argument to set tdep->tdesc properly.  OK for trunk?

Thanks.


-- 
H.J.
---
2012-05-31  Mark Kettenis  <kettenis@gnu.org>
	    H.J. Lu  <hongjiu.lu@intel.com>

	* amd64-linux-tdep.c (amd64_linux_init_abi): Renamed to ...
	(amd64_linux_init): This.  Add an argument, amd64_linux_tdesc.
	(amd64_linux_init_abi): Call amd64_linux_init.
	(amd64_x32_linux_init_abi): New function.
	(_initialize_amd64_linux_tdep): Register bfd_mach_x64_32 with
	amd64_x32_linux_init_abi.

	* amd64-tdep.c (amd64_dword_names): Add "eip".
	(amd64_x32_pseudo_register_type): New function.
	(amd64_x32_init): Likewise.
	(amd64_x32_init_abi): Likewise.
	(amd64_init_abi): Renamed to ...
	(amd64_init): This. Add an argument, amd64_tdesc.
	(amd64_init_abi): Call amd64_init.

	* amd64-tdep.h (amd64_x32_init_abi): New prototype.
	(amd64_x32_init): Likewise.

	* i386-tdep.c (i386_pseudo_register_type): Make it global.

	* i386-tdep.h (i386_pseudo_register_type): New prototype.

diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c
index 42dc89a..23bf318 100644
--- a/gdb/amd64-linux-tdep.c
+++ b/gdb/amd64-linux-tdep.c
@@ -1288,7 +1288,8 @@ amd64_linux_core_read_description (struct
gdbarch *gdbarch,
 }

 static void
-amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+amd64_linux_init (struct gdbarch_info info, struct gdbarch *gdbarch,
+		  const struct target_desc *amd64_linux_tdesc)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
   const struct target_desc *tdesc = info.target_desc;
@@ -1310,9 +1311,10 @@ amd64_linux_init_abi (struct gdbarch_info info,
struct gdbarch *gdbarch)
   set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);

   if (! tdesc_has_registers (tdesc))
-    tdesc = tdesc_amd64_linux;
+    tdesc = amd64_linux_tdesc;
   tdep->tdesc = tdesc;

+  /* tdep->tdesc can't be changed after being used here.  */
   feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
   if (feature == NULL)
     return;
@@ -1543,6 +1545,24 @@ amd64_linux_init_abi (struct gdbarch_info info,
struct gdbarch *gdbarch)

   tdep->i386_syscall_record = amd64_linux_syscall_record;
 }
+
+static void
+amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  amd64_linux_init (info, gdbarch, tdesc_amd64_linux);
+}
+
+static void
+amd64_x32_linux_init_abi (struct gdbarch_info info,
+			  struct gdbarch *gdbarch)
+{
+  amd64_linux_init (info, gdbarch, tdesc_x32_linux);
+  amd64_x32_init (gdbarch);
+
+   /* GNU/Linux uses SVR4-style shared libraries.  */
+  set_solib_svr4_fetch_link_map_offsets
+    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
+}



 /* Provide a prototype to silence -Wmissing-prototypes.  */
@@ -1553,6 +1573,8 @@ _initialize_amd64_linux_tdep (void)
 {
   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
 			  GDB_OSABI_LINUX, amd64_linux_init_abi);
+  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
+			  GDB_OSABI_LINUX, amd64_x32_linux_init_abi);

   /* Initialize the Linux target description.  */
   initialize_tdesc_amd64_linux ();
diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
index df91a51..47f8019 100644
--- a/gdb/amd64-tdep.c
+++ b/gdb/amd64-tdep.c
@@ -258,9 +258,32 @@ static const char *amd64_word_names[] =
 static const char *amd64_dword_names[] =
 {
   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp",
-  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
+  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
+  "eip"
 };

+/* Return the GDB type object for the "standard" data type of data in
+   register REGNUM.  Only used for x32.  */
+
+static struct type *
+amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
+{
+  /* Use pointer types for ebp, esp and eip registers in x32.  */
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  switch (regnum - tdep->eax_regnum)
+    {
+    default:
+      break;
+    case AMD64_RBP_REGNUM:	/* ebp  */
+    case AMD64_RSP_REGNUM:	/* esp	*/
+      return builtin_type (gdbarch)->builtin_data_ptr;
+    case AMD64_RIP_REGNUM:	/* eip */
+      return builtin_type (gdbarch)->builtin_func_ptr;
+    }
+
+  return i386_pseudo_register_type (gdbarch, regnum);
+}
+
 /* Return the name of register REGNUM.  */

 static const char *
@@ -2606,8 +2629,9 @@ static const int amd64_record_regmap[] =
   AMD64_DS_REGNUM, AMD64_ES_REGNUM, AMD64_FS_REGNUM, AMD64_GS_REGNUM
 };

-void
-amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+static void
+amd64_init (struct gdbarch_info info, struct gdbarch *gdbarch,
+	    const struct target_desc *amd64_tdesc)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
   const struct target_desc *tdesc = info.target_desc;
@@ -2617,12 +2641,13 @@ amd64_init_abi (struct gdbarch_info info,
struct gdbarch *gdbarch)
   tdep->sizeof_fpregset = I387_SIZEOF_FXSAVE;

   if (! tdesc_has_registers (tdesc))
-    tdesc = tdesc_amd64;
+    tdesc = amd64_tdesc;
   tdep->tdesc = tdesc;

   tdep->num_core_regs = AMD64_NUM_GREGS + I387_NUM_REGS;
   tdep->register_names = amd64_register_names;

+  /* tdep->tdesc can't be changed after being used here.  */
   if (tdesc_find_feature (tdesc, "org.gnu.gdb.i386.avx") != NULL)
     {
       tdep->ymmh_register_names = amd64_ymmh_names;
@@ -2730,6 +2755,32 @@ amd64_init_abi (struct gdbarch_info info,
struct gdbarch *gdbarch)
 					i386_stap_parse_special_token);
 }

+void
+amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  amd64_init (info, gdbarch, tdesc_amd64);
+}
+
+void
+amd64_x32_init (struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  tdep->num_dword_regs = 17;
+
+  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
+
+  set_gdbarch_long_bit (gdbarch, 32);
+  set_gdbarch_ptr_bit (gdbarch, 32);
+}
+
+void
+amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  amd64_init (info, gdbarch, tdesc_x32);
+  amd64_x32_init (gdbarch);
+}
+
 /* Provide a prototype to silence -Wmissing-prototypes.  */
 void _initialize_amd64_tdep (void);

diff --git a/gdb/amd64-tdep.h b/gdb/amd64-tdep.h
index 1ed109c..ce47ae7 100644
--- a/gdb/amd64-tdep.h
+++ b/gdb/amd64-tdep.h
@@ -80,6 +80,9 @@ extern void amd64_displaced_step_fixup (struct
gdbarch *gdbarch,
 					struct regcache *regs);

 extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
+extern void amd64_x32_init_abi (struct gdbarch_info info,
+				struct gdbarch *gdbarch);
+extern void amd64_x32_init (struct gdbarch *gdbarch);

 /* Fill register REGNUM in REGCACHE with the appropriate
    floating-point or SSE register value from *FXSAVE.  If REGNUM is
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 5b04505..6333556 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -2780,7 +2780,7 @@ i386_mmx_type (struct gdbarch *gdbarch)
 /* Return the GDB type object for the "standard" data type of data in
    register REGNUM.  */

-static struct type *
+struct type *
 i386_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
 {
   if (i386_mmx_regnum_p (gdbarch, regnum))
diff --git a/gdb/i386-tdep.h b/gdb/i386-tdep.h
index f297ae7..a12b1f5 100644
--- a/gdb/i386-tdep.h
+++ b/gdb/i386-tdep.h
@@ -307,6 +307,7 @@ extern int i386_dword_regnum_p (struct gdbarch
*gdbarch, int regnum);
 extern int i386_xmm_regnum_p (struct gdbarch *gdbarch, int regnum);
 extern int i386_ymm_regnum_p (struct gdbarch *gdbarch, int regnum);

+extern struct type *i386_pseudo_register_type (struct gdbarch *, int);
 extern const char *i386_pseudo_register_name (struct gdbarch *gdbarch,
 					      int regnum);


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-05-31 18:18                 ` H.J. Lu
@ 2012-06-05 12:58                   ` H.J. Lu
  2012-06-05 13:16                     ` Mark Kettenis
  2012-06-10 21:52                   ` Mark Kettenis
  1 sibling, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2012-06-05 12:58 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

On Thu, May 31, 2012 at 11:18 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, May 28, 2012 at 2:18 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, May 28, 2012 at 1:26 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>>>> Date: Sun, 20 May 2012 15:48:54 -0700
>>>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>>>
>>>> Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
>>>> since amd64_x32_linux_init_abi can't call amd64_init_abi after
>>>> calling amd64_linux_init_abi.
>>>
>>> I guess multiple-inheritance is a bad idea, even when implemented in C ;)
>>>
>>> I really do think that amd64_x32_linux_init_abi() should call
>>> amd64_x32_init_abi().  That way it is immediately obvious that the OS-specific ABI inherits everything from the generic ABI.
>>
>> X32 kernel interface are highly OS specific.  Different OSes can implement
>> very different kernel interfaces.  The only generic x32 bits are
>>
>>  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>>
>>  tdep->num_dword_regs = 17;
>>
>>  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
>>
>>  set_gdbarch_long_bit (gdbarch, 32);
>>  set_gdbarch_ptr_bit (gdbarch, 32);
>>
>> They are the same for all x32 OSes since they are determined by
>> hardware, not OS.
>>
>>> In order too avoid too much code duplication, the common bits should
>>> be split out from amd64_linux_init_abi() into a seperate function that
>>> gets called from both amd64_linux_init_abi() and
>>> amd64_x32_linux_init_abi().  As I wrote earlier, it isn't entirely
>>> obvious that everything in amd64_linix_init_abi() applies to the x32
>>> ABI.  So we should be conservative in moving stuff into the common
>>> function.  In fact it might be a good idea to start out with something
>>> like the attached diff, and gradually move things over.
>>
>> Linux x32 kernel interface shares > 90% of Linux amd64 kernel
>> interface (309 system calls out of 337 are the same).  See
>> 64-bit system call table in Linux kernel 3.4:
>>
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=arch/x86/syscalls/syscall_64.tbl;h=dd29a9ea27c560a9d2fcb6e1c2983f8b8e9be407;hb=HEAD
>>
>> I believe we should start with sharing everything between Linux/x32
>> and Linux/amd64.  We can update x32 part as we go.
>>
>
>
> Here is the updated patch.  I added amd64_x32_init for generic x32
> setting.  It can be used by all x32 init_abi functions.  Since
> tdep->tdesc can't be changed after being used, I renamed
> amd64_init_abi/amd64_init_abi to amd64_init/amd64_linux_init
> to take an  argument to set tdep->tdesc properly.  OK for trunk?
>
> Thanks.
>

Hi Mark,

Do you have a chance to take a look at this?

Thanks.


H.J.
> --
> H.J.
> ---
> 2012-05-31  Mark Kettenis  <kettenis@gnu.org>
>            H.J. Lu  <hongjiu.lu@intel.com>
>
>        * amd64-linux-tdep.c (amd64_linux_init_abi): Renamed to ...
>        (amd64_linux_init): This.  Add an argument, amd64_linux_tdesc.
>        (amd64_linux_init_abi): Call amd64_linux_init.
>        (amd64_x32_linux_init_abi): New function.
>        (_initialize_amd64_linux_tdep): Register bfd_mach_x64_32 with
>        amd64_x32_linux_init_abi.
>
>        * amd64-tdep.c (amd64_dword_names): Add "eip".
>        (amd64_x32_pseudo_register_type): New function.
>        (amd64_x32_init): Likewise.
>        (amd64_x32_init_abi): Likewise.
>        (amd64_init_abi): Renamed to ...
>        (amd64_init): This. Add an argument, amd64_tdesc.
>        (amd64_init_abi): Call amd64_init.
>
>        * amd64-tdep.h (amd64_x32_init_abi): New prototype.
>        (amd64_x32_init): Likewise.
>
>        * i386-tdep.c (i386_pseudo_register_type): Make it global.
>
>        * i386-tdep.h (i386_pseudo_register_type): New prototype.
>
> diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c
> index 42dc89a..23bf318 100644
> --- a/gdb/amd64-linux-tdep.c
> +++ b/gdb/amd64-linux-tdep.c
> @@ -1288,7 +1288,8 @@ amd64_linux_core_read_description (struct
> gdbarch *gdbarch,
>  }
>
>  static void
> -amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +amd64_linux_init (struct gdbarch_info info, struct gdbarch *gdbarch,
> +                 const struct target_desc *amd64_linux_tdesc)
>  {
>   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>   const struct target_desc *tdesc = info.target_desc;
> @@ -1310,9 +1311,10 @@ amd64_linux_init_abi (struct gdbarch_info info,
> struct gdbarch *gdbarch)
>   set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
>
>   if (! tdesc_has_registers (tdesc))
> -    tdesc = tdesc_amd64_linux;
> +    tdesc = amd64_linux_tdesc;
>   tdep->tdesc = tdesc;
>
> +  /* tdep->tdesc can't be changed after being used here.  */
>   feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
>   if (feature == NULL)
>     return;
> @@ -1543,6 +1545,24 @@ amd64_linux_init_abi (struct gdbarch_info info,
> struct gdbarch *gdbarch)
>
>   tdep->i386_syscall_record = amd64_linux_syscall_record;
>  }
> +
> +static void
> +amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  amd64_linux_init (info, gdbarch, tdesc_amd64_linux);
> +}
> +
> +static void
> +amd64_x32_linux_init_abi (struct gdbarch_info info,
> +                         struct gdbarch *gdbarch)
> +{
> +  amd64_linux_init (info, gdbarch, tdesc_x32_linux);
> +  amd64_x32_init (gdbarch);
> +
> +   /* GNU/Linux uses SVR4-style shared libraries.  */
> +  set_solib_svr4_fetch_link_map_offsets
> +    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
> +}
>
>
>
>  /* Provide a prototype to silence -Wmissing-prototypes.  */
> @@ -1553,6 +1573,8 @@ _initialize_amd64_linux_tdep (void)
>  {
>   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
>                          GDB_OSABI_LINUX, amd64_linux_init_abi);
> +  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
> +                         GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
>
>   /* Initialize the Linux target description.  */
>   initialize_tdesc_amd64_linux ();
> diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
> index df91a51..47f8019 100644
> --- a/gdb/amd64-tdep.c
> +++ b/gdb/amd64-tdep.c
> @@ -258,9 +258,32 @@ static const char *amd64_word_names[] =
>  static const char *amd64_dword_names[] =
>  {
>   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp",
> -  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
> +  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
> +  "eip"
>  };
>
> +/* Return the GDB type object for the "standard" data type of data in
> +   register REGNUM.  Only used for x32.  */
> +
> +static struct type *
> +amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
> +{
> +  /* Use pointer types for ebp, esp and eip registers in x32.  */
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  switch (regnum - tdep->eax_regnum)
> +    {
> +    default:
> +      break;
> +    case AMD64_RBP_REGNUM:     /* ebp  */
> +    case AMD64_RSP_REGNUM:     /* esp  */
> +      return builtin_type (gdbarch)->builtin_data_ptr;
> +    case AMD64_RIP_REGNUM:     /* eip */
> +      return builtin_type (gdbarch)->builtin_func_ptr;
> +    }
> +
> +  return i386_pseudo_register_type (gdbarch, regnum);
> +}
> +
>  /* Return the name of register REGNUM.  */
>
>  static const char *
> @@ -2606,8 +2629,9 @@ static const int amd64_record_regmap[] =
>   AMD64_DS_REGNUM, AMD64_ES_REGNUM, AMD64_FS_REGNUM, AMD64_GS_REGNUM
>  };
>
> -void
> -amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +static void
> +amd64_init (struct gdbarch_info info, struct gdbarch *gdbarch,
> +           const struct target_desc *amd64_tdesc)
>  {
>   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>   const struct target_desc *tdesc = info.target_desc;
> @@ -2617,12 +2641,13 @@ amd64_init_abi (struct gdbarch_info info,
> struct gdbarch *gdbarch)
>   tdep->sizeof_fpregset = I387_SIZEOF_FXSAVE;
>
>   if (! tdesc_has_registers (tdesc))
> -    tdesc = tdesc_amd64;
> +    tdesc = amd64_tdesc;
>   tdep->tdesc = tdesc;
>
>   tdep->num_core_regs = AMD64_NUM_GREGS + I387_NUM_REGS;
>   tdep->register_names = amd64_register_names;
>
> +  /* tdep->tdesc can't be changed after being used here.  */
>   if (tdesc_find_feature (tdesc, "org.gnu.gdb.i386.avx") != NULL)
>     {
>       tdep->ymmh_register_names = amd64_ymmh_names;
> @@ -2730,6 +2755,32 @@ amd64_init_abi (struct gdbarch_info info,
> struct gdbarch *gdbarch)
>                                        i386_stap_parse_special_token);
>  }
>
> +void
> +amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  amd64_init (info, gdbarch, tdesc_amd64);
> +}
> +
> +void
> +amd64_x32_init (struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +
> +  tdep->num_dword_regs = 17;
> +
> +  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
> +
> +  set_gdbarch_long_bit (gdbarch, 32);
> +  set_gdbarch_ptr_bit (gdbarch, 32);
> +}
> +
> +void
> +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  amd64_init (info, gdbarch, tdesc_x32);
> +  amd64_x32_init (gdbarch);
> +}
> +
>  /* Provide a prototype to silence -Wmissing-prototypes.  */
>  void _initialize_amd64_tdep (void);
>
> diff --git a/gdb/amd64-tdep.h b/gdb/amd64-tdep.h
> index 1ed109c..ce47ae7 100644
> --- a/gdb/amd64-tdep.h
> +++ b/gdb/amd64-tdep.h
> @@ -80,6 +80,9 @@ extern void amd64_displaced_step_fixup (struct
> gdbarch *gdbarch,
>                                        struct regcache *regs);
>
>  extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
> +extern void amd64_x32_init_abi (struct gdbarch_info info,
> +                               struct gdbarch *gdbarch);
> +extern void amd64_x32_init (struct gdbarch *gdbarch);
>
>  /* Fill register REGNUM in REGCACHE with the appropriate
>    floating-point or SSE register value from *FXSAVE.  If REGNUM is
> diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
> index 5b04505..6333556 100644
> --- a/gdb/i386-tdep.c
> +++ b/gdb/i386-tdep.c
> @@ -2780,7 +2780,7 @@ i386_mmx_type (struct gdbarch *gdbarch)
>  /* Return the GDB type object for the "standard" data type of data in
>    register REGNUM.  */
>
> -static struct type *
> +struct type *
>  i386_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
>  {
>   if (i386_mmx_regnum_p (gdbarch, regnum))
> diff --git a/gdb/i386-tdep.h b/gdb/i386-tdep.h
> index f297ae7..a12b1f5 100644
> --- a/gdb/i386-tdep.h
> +++ b/gdb/i386-tdep.h
> @@ -307,6 +307,7 @@ extern int i386_dword_regnum_p (struct gdbarch
> *gdbarch, int regnum);
>  extern int i386_xmm_regnum_p (struct gdbarch *gdbarch, int regnum);
>  extern int i386_ymm_regnum_p (struct gdbarch *gdbarch, int regnum);
>
> +extern struct type *i386_pseudo_register_type (struct gdbarch *, int);
>  extern const char *i386_pseudo_register_name (struct gdbarch *gdbarch,
>                                              int regnum);


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-06-05 12:58                   ` H.J. Lu
@ 2012-06-05 13:16                     ` Mark Kettenis
  2012-06-09 14:30                       ` H.J. Lu
  0 siblings, 1 reply; 42+ messages in thread
From: Mark Kettenis @ 2012-06-05 13:16 UTC (permalink / raw)
  To: hjl.tools; +Cc: gdb-patches

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]

> Date: Tue, 5 Jun 2012 05:58:18 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> On Thu, May 31, 2012 at 11:18 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > On Mon, May 28, 2012 at 2:18 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> >> On Mon, May 28, 2012 at 1:26 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >>>> Date: Sun, 20 May 2012 15:48:54 -0700
> >>>> From: "H.J. Lu" <hjl.tools@gmail.com>
> >>>>
> >>>> Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
> >>>> since amd64_x32_linux_init_abi can't call amd64_init_abi after
> >>>> calling amd64_linux_init_abi.
> >>>
> >>> I guess multiple-inheritance is a bad idea, even when implemented in C ;)
> >>>
> >>> I really do think that amd64_x32_linux_init_abi() should call
> >>> amd64_x32_init_abi().  That way it is immediately obvious that the OS-specific ABI inherits everything from the generic ABI.
> >>
> >> X32 kernel interface are highly OS specific.  Different OSes can implement
> >> very different kernel interfaces.  The only generic x32 bits are
> >>
> >>  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> >>
> >>  tdep->num_dword_regs = 17;
> >>
> >>  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
> >>
> >>  set_gdbarch_long_bit (gdbarch, 32);
> >>  set_gdbarch_ptr_bit (gdbarch, 32);
> >>
> >> They are the same for all x32 OSes since they are determined by
> >> hardware, not OS.
> >>
> >>> In order too avoid too much code duplication, the common bits should
> >>> be split out from amd64_linux_init_abi() into a seperate function that
> >>> gets called from both amd64_linux_init_abi() and
> >>> amd64_x32_linux_init_abi().  As I wrote earlier, it isn't entirely
> >>> obvious that everything in amd64_linix_init_abi() applies to the x32
> >>> ABI.  So we should be conservative in moving stuff into the common
> >>> function.  In fact it might be a good idea to start out with something
> >>> like the attached diff, and gradually move things over.
> >>
> >> Linux x32 kernel interface shares > 90% of Linux amd64 kernel
> >> interface (309 system calls out of 337 are the same).  See
> >> 64-bit system call table in Linux kernel 3.4:
> >>
> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=arch/x86/syscalls/syscall_64.tbl;h=dd29a9ea27c560a9d2fcb6e1c2983f8b8e9be407;hb=HEAD
> >>
> >> I believe we should start with sharing everything between Linux/x32
> >> and Linux/amd64.  We can update x32 part as we go.
> >>
> >
> >
> > Here is the updated patch.  I added amd64_x32_init for generic x32
> > setting.  It can be used by all x32 init_abi functions.  Since
> > tdep->tdesc can't be changed after being used, I renamed
> > amd64_init_abi/amd64_init_abi to amd64_init/amd64_linux_init
> > to take an  argument to set tdep->tdesc properly.  OK for trunk?
> >
> > Thanks.
> >
> 
> Hi Mark,
> 
> Do you have a chance to take a look at this?

Sorry, no.  Unliekly to be able to look at it until Thrusday evening.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-05-30 22:04   ` Joel Brobecker
@ 2012-06-07 19:36     ` Maciej W. Rozycki
  2012-06-11 14:58       ` Joel Brobecker
  0 siblings, 1 reply; 42+ messages in thread
From: Maciej W. Rozycki @ 2012-06-07 19:36 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Jan Kratochvil, gdb-patches

On Wed, 30 May 2012, Joel Brobecker wrote:

> > [Jan] Fix gdb.cp/gdb2495.exp regression with gcc-4.7
> >     http://sourceware.org/ml/gdb-patches/2012-03/msg00357.html 1/2
> >     http://sourceware.org/ml/gdb-patches/2012-03/msg00358.html 2/2 
> >  - This is not a regression of GDB itself but it is a regression of the whole
> >    GNU toolchain.  There is missing some protection against stale breakpoints
> >    on stack (ON_STACK) after longjmps/throws (I do not remember it much now).
> >    I use in Fedora these patches.
> > 
> > [Jan] workaround stale frame_info * ( http://sourceware.org/bugzilla/show_bug.cgi?id=13866 )
> >     http://sourceware.org/ml/gdb-patches/2012-04/msg00058.html 
> >  - some proper fix will almost sure not get into 7.5 so maybe to fix "finish"
> >    crashes the workaround could be even applied for FSF GDB HEAD?
> >    I use in Fedora this workaround.
> 
> Thanks for the heads up, Jan. Looks like me might want to delay
> the branch. I can't remember that Doug said he was done on his end.
> 
> There is no real hurry until the end of the month. After that,
> my schedule gets really tight again, pretty much until mid-september.
> I still expect to be able to make the branch, and possibly produce
> the release, but I might not be able to push for regular updates
> the way I like to do...

 Ouch, that's a tad inconvenient to me, I had hoped for the branch to have 
been made so that the MIPS changes I'm working on right now can be safely 
applied to trunk without the risk of disturbing the upcoming release.  
That includes the floating-point changes currently on my plate -- these 
already published and some more stuff still ongoing.  Plus the ISA bit 
discussion.

 I do understand the importance of the issues concerned by Jan of course, 
but I also feel like deferring the MIPS stuff for a month and likely more 
is going to get me distracted too much by something else, so given the 
circumstances may I kindly ask people to have a look into my proposal and 
request for discussion about the generic parts of the ISA bit changes as 
posted here:

http://sourceware.org/ml/gdb-patches/2012-05/msg00515.html

(of course any comments about the MIPS parts are welcome as well, but 
these bits I am pretty much confident about).

 While this is still possibly too brave a change to be included in 7.5 at 
such a short notice, I think it will make sense to start the discussion 
now rather than later, so that it won't be another month after 7.5 has 
branched before it can finally go in.  Thanks!

  Maciej


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-06-05 13:16                     ` Mark Kettenis
@ 2012-06-09 14:30                       ` H.J. Lu
  0 siblings, 0 replies; 42+ messages in thread
From: H.J. Lu @ 2012-06-09 14:30 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

On Tue, Jun 5, 2012 at 6:16 AM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Tue, 5 Jun 2012 05:58:18 -0700
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>
>> On Thu, May 31, 2012 at 11:18 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > On Mon, May 28, 2012 at 2:18 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> >> On Mon, May 28, 2012 at 1:26 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> >>>> Date: Sun, 20 May 2012 15:48:54 -0700
>> >>>> From: "H.J. Lu" <hjl.tools@gmail.com>
>> >>>>
>> >>>> Does this one look OK.  I extracted x32_init_abi from amd64_x32_init_abi
>> >>>> since amd64_x32_linux_init_abi can't call amd64_init_abi after
>> >>>> calling amd64_linux_init_abi.
>> >>>
>> >>> I guess multiple-inheritance is a bad idea, even when implemented in C ;)
>> >>>
>> >>> I really do think that amd64_x32_linux_init_abi() should call
>> >>> amd64_x32_init_abi().  That way it is immediately obvious that the OS-specific ABI inherits everything from the generic ABI.
>> >>
>> >> X32 kernel interface are highly OS specific.  Different OSes can implement
>> >> very different kernel interfaces.  The only generic x32 bits are
>> >>
>> >>  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>> >>
>> >>  tdep->num_dword_regs = 17;
>> >>
>> >>  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
>> >>
>> >>  set_gdbarch_long_bit (gdbarch, 32);
>> >>  set_gdbarch_ptr_bit (gdbarch, 32);
>> >>
>> >> They are the same for all x32 OSes since they are determined by
>> >> hardware, not OS.
>> >>
>> >>> In order too avoid too much code duplication, the common bits should
>> >>> be split out from amd64_linux_init_abi() into a seperate function that
>> >>> gets called from both amd64_linux_init_abi() and
>> >>> amd64_x32_linux_init_abi().  As I wrote earlier, it isn't entirely
>> >>> obvious that everything in amd64_linix_init_abi() applies to the x32
>> >>> ABI.  So we should be conservative in moving stuff into the common
>> >>> function.  In fact it might be a good idea to start out with something
>> >>> like the attached diff, and gradually move things over.
>> >>
>> >> Linux x32 kernel interface shares > 90% of Linux amd64 kernel
>> >> interface (309 system calls out of 337 are the same).  See
>> >> 64-bit system call table in Linux kernel 3.4:
>> >>
>> >> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=arch/x86/syscalls/syscall_64.tbl;h=dd29a9ea27c560a9d2fcb6e1c2983f8b8e9be407;hb=HEAD
>> >>
>> >> I believe we should start with sharing everything between Linux/x32
>> >> and Linux/amd64.  We can update x32 part as we go.
>> >>
>> >
>> >
>> > Here is the updated patch.  I added amd64_x32_init for generic x32
>> > setting.  It can be used by all x32 init_abi functions.  Since
>> > tdep->tdesc can't be changed after being used, I renamed
>> > amd64_init_abi/amd64_init_abi to amd64_init/amd64_linux_init
>> > to take an  argument to set tdep->tdesc properly.  OK for trunk?
>> >
>> > Thanks.
>> >
>>
>> Hi Mark,
>>
>> Do you have a chance to take a look at this?
>
> Sorry, no.  Unliekly to be able to look at it until Thrusday evening.

Hi Mark,

Have you got time to review my change?

Thanks.


-- 
H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-05-31 18:18                 ` H.J. Lu
  2012-06-05 12:58                   ` H.J. Lu
@ 2012-06-10 21:52                   ` Mark Kettenis
  2012-06-11 13:42                     ` H.J. Lu
  1 sibling, 1 reply; 42+ messages in thread
From: Mark Kettenis @ 2012-06-10 21:52 UTC (permalink / raw)
  To: hjl.tools; +Cc: gdb-patches

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8661 bytes --]

> Date: Thu, 31 May 2012 11:18:02 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> > I think this is the wrong approach for x32 support. We should
> > break amd64_x32_init_abi into 2 parts:
> >
> > 1. OS specific part.  It should be private to amd64-tdep.c.

There is no OS specific code in amd64-tdep.c.  Only code that
implements the generic OS-agnistic low-level ABI.

> > 2. Generic part.  It should be exported from amd64-tdep.c and can
> > be used by all x32 OSes.

Yes, and that entry point should be amd64_x32_init_abi().  That is the
pattern that has been established, and I see no reason to deviate from
it.  So here is the diff I suggested before again with one change: it
moves most of the amd64 Linux support bits into its own function and
calls that from both amd64_linux_init_abi() and
amd64_x32_linux_init_abi().  I'm sure some of those bits are wrong for
x32, but if you want to fix things up from that end, it is fine with
me.  The important bit that I care about is getting the inheritance
structure right.


Index: amd64-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
retrieving revision 1.50
diff -u -p -r1.50 amd64-linux-tdep.c
--- amd64-linux-tdep.c	12 May 2012 08:54:03 -0000	1.50
+++ amd64-linux-tdep.c	10 Jun 2012 21:39:08 -0000
@@ -1288,41 +1288,12 @@ amd64_linux_core_read_description (struc
 }
 
 static void
-amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+amd64_linux_init_abi_common(struct gdbarch_info info, struct gdbarch *gdbarch)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
-  const struct target_desc *tdesc = info.target_desc;
-  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
-  const struct tdesc_feature *feature;
-  int valid_p;
-
-  gdb_assert (tdesc_data);
 
   linux_init_abi (info, gdbarch);
 
-  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
-  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
-  tdep->sizeof_gregset = 27 * 8;
-
-  amd64_init_abi (info, gdbarch);
-
-  /* Reserve a number for orig_rax.  */
-  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
-
-  if (! tdesc_has_registers (tdesc))
-    tdesc = tdesc_amd64_linux;
-  tdep->tdesc = tdesc;
-
-  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
-  if (feature == NULL)
-    return;
-
-  valid_p = tdesc_numbered_register (feature, tdesc_data,
-				     AMD64_LINUX_ORIG_RAX_REGNUM,
-				     "orig_rax");
-  if (!valid_p)
-    return;
-
   tdep->sigtramp_p = amd64_linux_sigtramp_p;
   tdep->sigcontext_addr = amd64_linux_sigcontext_addr;
   tdep->sc_reg_offset = amd64_linux_sc_reg_offset;
@@ -1330,10 +1301,6 @@ amd64_linux_init_abi (struct gdbarch_inf
 
   tdep->xsave_xcr0_offset = I386_LINUX_XSAVE_XCR0_OFFSET;
 
-  /* GNU/Linux uses SVR4-style shared libraries.  */
-  set_solib_svr4_fetch_link_map_offsets
-    (gdbarch, svr4_lp64_fetch_link_map_offsets);
-
   /* Add the %orig_rax register used for syscall restarting.  */
   set_gdbarch_write_pc (gdbarch, amd64_linux_write_pc);
 
@@ -1543,6 +1510,88 @@ amd64_linux_init_abi (struct gdbarch_inf
 
   tdep->i386_syscall_record = amd64_linux_syscall_record;
 }
+
+static void
+amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
+  const struct tdesc_feature *feature;
+  int valid_p;
+
+  gdb_assert (tdesc_data);
+
+  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
+  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
+  tdep->sizeof_gregset = 27 * 8;
+
+  amd64_init_abi (info, gdbarch);
+
+  /* Reserve a number for orig_rax.  */
+  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_amd64_linux;
+  tdep->tdesc = tdesc;
+
+  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
+  if (feature == NULL)
+    return;
+
+  valid_p = tdesc_numbered_register (feature, tdesc_data,
+				     AMD64_LINUX_ORIG_RAX_REGNUM,
+				     "orig_rax");
+  if (!valid_p)
+    return;
+
+  amd64_linux_init_abi_common (info, gdbarch);
+
+  /* GNU/Linux uses SVR4-style shared libraries.  */
+  set_solib_svr4_fetch_link_map_offsets
+    (gdbarch, svr4_lp64_fetch_link_map_offsets);
+}
+
+static void
+amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
+  const struct tdesc_feature *feature;
+  int valid_p;
+
+  gdb_assert (tdesc_data);
+
+  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
+  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
+  tdep->sizeof_gregset = 27 * 8;
+
+  amd64_x32_init_abi (info, gdbarch);
+
+  /* Reserve a number for orig_rax.  */
+  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_x32_linux;
+  tdep->tdesc = tdesc;
+
+  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
+  if (feature == NULL)
+    return;
+
+  valid_p = tdesc_numbered_register (feature, tdesc_data,
+				     AMD64_LINUX_ORIG_RAX_REGNUM,
+				     "orig_rax");
+  if (!valid_p)
+    return;
+
+  amd64_linux_init_abi_common (info, gdbarch);
+
+  /* GNU/Linux uses SVR4-style shared libraries.  */
+  set_solib_svr4_fetch_link_map_offsets
+    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
+}
 \f
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
@@ -1553,6 +1602,8 @@ _initialize_amd64_linux_tdep (void)
 {
   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
 			  GDB_OSABI_LINUX, amd64_linux_init_abi);
+  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
+			  GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
 
   /* Initialize the Linux target description.  */
   initialize_tdesc_amd64_linux ();
Index: amd64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
retrieving revision 1.104
diff -u -p -r1.104 amd64-tdep.c
--- amd64-tdep.c	14 May 2012 18:56:40 -0000	1.104
+++ amd64-tdep.c	10 Jun 2012 21:39:09 -0000
@@ -258,7 +258,8 @@ static const char *amd64_word_names[] =
 static const char *amd64_dword_names[] =
 {
   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp", 
-  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
+  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
+  "eip"
 };
 
 /* Return the name of register REGNUM.  */
@@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info
   set_gdbarch_stap_parse_special_token (gdbarch,
 					i386_stap_parse_special_token);
 }
+\f
+
+static struct type *
+amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  switch (regnum - tdep->eax_regnum)
+    {
+    case AMD64_RBP_REGNUM:	/* %ebp */
+    case AMD64_RSP_REGNUM:	/* %esp */
+      return builtin_type (gdbarch)->builtin_data_ptr;
+    case AMD64_RIP_REGNUM:	/* %eip */
+      return builtin_type (gdbarch)->builtin_func_ptr;
+    }
+
+  return i386_pseudo_register_type (gdbarch, regnum);
+}
+
+void
+amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+
+  amd64_init_abi (info, gdbarch);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_x32;
+  tdep->tdesc = tdesc;
+
+  tdep->num_dword_regs = 17;
+  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
+
+  set_gdbarch_long_bit (gdbarch, 32);
+  set_gdbarch_ptr_bit (gdbarch, 32);
+}
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
 void _initialize_amd64_tdep (void);
Index: amd64-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.h,v
retrieving revision 1.21
diff -u -p -r1.21 amd64-tdep.h
--- amd64-tdep.h	4 Jan 2012 08:16:56 -0000	1.21
+++ amd64-tdep.h	10 Jun 2012 21:39:09 -0000
@@ -80,6 +80,8 @@ extern void amd64_displaced_step_fixup (
 					struct regcache *regs);
 
 extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
+extern void amd64_x32_init_abi (struct gdbarch_info info,
+				struct gdbarch *gdbarch);
 
 /* Fill register REGNUM in REGCACHE with the appropriate
    floating-point or SSE register value from *FXSAVE.  If REGNUM is



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-06-10 21:52                   ` Mark Kettenis
@ 2012-06-11 13:42                     ` H.J. Lu
  2012-06-12 21:23                       ` Mark Kettenis
  0 siblings, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2012-06-11 13:42 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

On Sun, Jun 10, 2012 at 2:51 PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>> Date: Thu, 31 May 2012 11:18:02 -0700
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>>
>> > I think this is the wrong approach for x32 support. We should
>> > break amd64_x32_init_abi into 2 parts:
>> >
>> > 1. OS specific part.  It should be private to amd64-tdep.c.
>
> There is no OS specific code in amd64-tdep.c.  Only code that
> implements the generic OS-agnistic low-level ABI.
>
>> > 2. Generic part.  It should be exported from amd64-tdep.c and can
>> > be used by all x32 OSes.
>
> Yes, and that entry point should be amd64_x32_init_abi().  That is the
> pattern that has been established, and I see no reason to deviate from
> it.  So here is the diff I suggested before again with one change: it
> moves most of the amd64 Linux support bits into its own function and
> calls that from both amd64_linux_init_abi() and
> amd64_x32_linux_init_abi().  I'm sure some of those bits are wrong for
> x32, but if you want to fix things up from that end, it is fine with
> me.  The important bit that I care about is getting the inheritance
> structure right.
>
>
> Index: amd64-linux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 amd64-linux-tdep.c
> --- amd64-linux-tdep.c  12 May 2012 08:54:03 -0000      1.50
> +++ amd64-linux-tdep.c  10 Jun 2012 21:39:08 -0000
> @@ -1288,41 +1288,12 @@ amd64_linux_core_read_description (struc
>  }
>
>  static void
> -amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +amd64_linux_init_abi_common(struct gdbarch_info info, struct gdbarch *gdbarch)
>  {
>   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> -  const struct target_desc *tdesc = info.target_desc;
> -  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
> -  const struct tdesc_feature *feature;
> -  int valid_p;
> -
> -  gdb_assert (tdesc_data);
>
>   linux_init_abi (info, gdbarch);
>
> -  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
> -  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
> -  tdep->sizeof_gregset = 27 * 8;
> -
> -  amd64_init_abi (info, gdbarch);
> -
> -  /* Reserve a number for orig_rax.  */
> -  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
> -
> -  if (! tdesc_has_registers (tdesc))
> -    tdesc = tdesc_amd64_linux;
> -  tdep->tdesc = tdesc;
> -
> -  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
> -  if (feature == NULL)
> -    return;
> -
> -  valid_p = tdesc_numbered_register (feature, tdesc_data,
> -                                    AMD64_LINUX_ORIG_RAX_REGNUM,
> -                                    "orig_rax");
> -  if (!valid_p)
> -    return;
> -
>   tdep->sigtramp_p = amd64_linux_sigtramp_p;
>   tdep->sigcontext_addr = amd64_linux_sigcontext_addr;
>   tdep->sc_reg_offset = amd64_linux_sc_reg_offset;
> @@ -1330,10 +1301,6 @@ amd64_linux_init_abi (struct gdbarch_inf
>
>   tdep->xsave_xcr0_offset = I386_LINUX_XSAVE_XCR0_OFFSET;
>
> -  /* GNU/Linux uses SVR4-style shared libraries.  */
> -  set_solib_svr4_fetch_link_map_offsets
> -    (gdbarch, svr4_lp64_fetch_link_map_offsets);
> -
>   /* Add the %orig_rax register used for syscall restarting.  */
>   set_gdbarch_write_pc (gdbarch, amd64_linux_write_pc);
>
> @@ -1543,6 +1510,88 @@ amd64_linux_init_abi (struct gdbarch_inf
>
>   tdep->i386_syscall_record = amd64_linux_syscall_record;
>  }
> +
> +static void
> +amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
> +  const struct tdesc_feature *feature;
> +  int valid_p;
> +
> +  gdb_assert (tdesc_data);
> +
> +  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
> +  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
> +  tdep->sizeof_gregset = 27 * 8;
> +
> +  amd64_init_abi (info, gdbarch);
> +
> +  /* Reserve a number for orig_rax.  */
> +  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_amd64_linux;
> +  tdep->tdesc = tdesc;
> +
> +  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
> +  if (feature == NULL)
> +    return;
> +
> +  valid_p = tdesc_numbered_register (feature, tdesc_data,
> +                                    AMD64_LINUX_ORIG_RAX_REGNUM,
> +                                    "orig_rax");
> +  if (!valid_p)
> +    return;
> +
> +  amd64_linux_init_abi_common (info, gdbarch);
> +
> +  /* GNU/Linux uses SVR4-style shared libraries.  */
> +  set_solib_svr4_fetch_link_map_offsets
> +    (gdbarch, svr4_lp64_fetch_link_map_offsets);
> +}
> +
> +static void
> +amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
> +  const struct tdesc_feature *feature;
> +  int valid_p;
> +
> +  gdb_assert (tdesc_data);
> +
> +  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
> +  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
> +  tdep->sizeof_gregset = 27 * 8;
> +
> +  amd64_x32_init_abi (info, gdbarch);
> +
> +  /* Reserve a number for orig_rax.  */
> +  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_x32_linux;
> +  tdep->tdesc = tdesc;
> +
> +  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
> +  if (feature == NULL)
> +    return;
> +
> +  valid_p = tdesc_numbered_register (feature, tdesc_data,
> +                                    AMD64_LINUX_ORIG_RAX_REGNUM,
> +                                    "orig_rax");
> +  if (!valid_p)
> +    return;
> +
> +  amd64_linux_init_abi_common (info, gdbarch);
> +
> +  /* GNU/Linux uses SVR4-style shared libraries.  */
> +  set_solib_svr4_fetch_link_map_offsets
> +    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
> +}
>
>
>  /* Provide a prototype to silence -Wmissing-prototypes.  */
> @@ -1553,6 +1602,8 @@ _initialize_amd64_linux_tdep (void)
>  {
>   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
>                          GDB_OSABI_LINUX, amd64_linux_init_abi);
> +  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
> +                         GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
>
>   /* Initialize the Linux target description.  */
>   initialize_tdesc_amd64_linux ();
> Index: amd64-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 amd64-tdep.c
> --- amd64-tdep.c        14 May 2012 18:56:40 -0000      1.104
> +++ amd64-tdep.c        10 Jun 2012 21:39:09 -0000
> @@ -258,7 +258,8 @@ static const char *amd64_word_names[] =
>  static const char *amd64_dword_names[] =
>  {
>   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp",
> -  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
> +  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
> +  "eip"
>  };
>
>  /* Return the name of register REGNUM.  */
> @@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info
>   set_gdbarch_stap_parse_special_token (gdbarch,
>                                        i386_stap_parse_special_token);
>  }
> +
> +
> +static struct type *
> +amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +
> +  switch (regnum - tdep->eax_regnum)
> +    {
> +    case AMD64_RBP_REGNUM:     /* %ebp */
> +    case AMD64_RSP_REGNUM:     /* %esp */
> +      return builtin_type (gdbarch)->builtin_data_ptr;
> +    case AMD64_RIP_REGNUM:     /* %eip */
> +      return builtin_type (gdbarch)->builtin_func_ptr;
> +    }
> +
> +  return i386_pseudo_register_type (gdbarch, regnum);
> +}
> +
> +void
> +amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> +  const struct target_desc *tdesc = info.target_desc;
> +
> +  amd64_init_abi (info, gdbarch);
> +
> +  if (! tdesc_has_registers (tdesc))
> +    tdesc = tdesc_x32;
> +  tdep->tdesc = tdesc;
> +
> +  tdep->num_dword_regs = 17;
> +  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
> +
> +  set_gdbarch_long_bit (gdbarch, 32);
> +  set_gdbarch_ptr_bit (gdbarch, 32);
> +}
>
>  /* Provide a prototype to silence -Wmissing-prototypes.  */
>  void _initialize_amd64_tdep (void);
> Index: amd64-tdep.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/amd64-tdep.h,v
> retrieving revision 1.21
> diff -u -p -r1.21 amd64-tdep.h
> --- amd64-tdep.h        4 Jan 2012 08:16:56 -0000       1.21
> +++ amd64-tdep.h        10 Jun 2012 21:39:09 -0000
> @@ -80,6 +80,8 @@ extern void amd64_displaced_step_fixup (
>                                        struct regcache *regs);
>
>  extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
> +extern void amd64_x32_init_abi (struct gdbarch_info info,
> +                               struct gdbarch *gdbarch);
>
>  /* Fill register REGNUM in REGCACHE with the appropriate
>    floating-point or SSE register value from *FXSAVE.  If REGNUM is
>
>

It works with the following patch.  Can you check it in?

Thanks.

-- 
H.J.
---
diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 5b04505..9cc2e30 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -2780,7 +2780,7 @@ i386_mmx_type (struct gdbarch *gdbarch)
 /* Return the GDB type object for the "standard" data type of data in
    register REGNUM.  */

-static struct type *
+struct type *
 i386_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
 {
   if (i386_mmx_regnum_p (gdbarch, regnum))
diff --git a/gdb/i386-tdep.h b/gdb/i386-tdep.h
index f297ae7..e1f7c44 100644
--- a/gdb/i386-tdep.h
+++ b/gdb/i386-tdep.h
@@ -307,6 +315,7 @@ extern int i386_dword_regnum_p (struct gdbarch
*gdbarch, int regnum);
 extern int i386_xmm_regnum_p (struct gdbarch *gdbarch, int regnum);
 extern int i386_ymm_regnum_p (struct gdbarch *gdbarch, int regnum);

+extern struct type *i386_pseudo_register_type (struct gdbarch *, int);
 extern const char *i386_pseudo_register_name (struct gdbarch *gdbarch,
 					      int regnum);


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-06-07 19:36     ` Maciej W. Rozycki
@ 2012-06-11 14:58       ` Joel Brobecker
  2012-06-12 15:39         ` Maciej W. Rozycki
  0 siblings, 1 reply; 42+ messages in thread
From: Joel Brobecker @ 2012-06-11 14:58 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Jan Kratochvil, gdb-patches

>  Ouch, that's a tad inconvenient to me, I had hoped for the branch to have 
> been made so that the MIPS changes I'm working on right now can be safely 
> applied to trunk without the risk of disturbing the upcoming release.  
> That includes the floating-point changes currently on my plate -- these 
> already published and some more stuff still ongoing.  Plus the ISA bit 
> discussion.

Understood.

>  I do understand the importance of the issues concerned by Jan of course, 
> but I also feel like deferring the MIPS stuff for a month and likely more 
> is going to get me distracted too much by something else,

Yeah, if the branch continues to be delayed much, we should go ahead
with your changes, and adjust if some regressions are found.

> so given the circumstances may I kindly ask people to have a look into
> my proposal and request for discussion about the generic parts of the
> ISA bit changes as posted here:
> 
> http://sourceware.org/ml/gdb-patches/2012-05/msg00515.html

I will try myself, but may not be the best reviewer.

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-05-20 14:59   ` Doug Evans
@ 2012-06-11 15:35     ` Joel Brobecker
  2012-06-11 15:52       ` Doug Evans
  2012-06-11 15:59       ` H.J. Lu
  0 siblings, 2 replies; 42+ messages in thread
From: Joel Brobecker @ 2012-06-11 15:35 UTC (permalink / raw)
  To: gdb-patches; +Cc: Doug Evans

Hello everyone,

We're now a week past our tentative date for 7.5 branching.
Can we have a list of issues still blocking the creation of that branch?

I reviewed Jan's patches, and I am hopeful that we'll be able to
move forward soon.

I am not sure about Doug's items. Doug?

Any other issues that have not been documented at our wiki page:
http://sourceware.org/gdb/wiki/GDB_7.5_Release
?

HJ, how far are you for x32?

Thanks,
-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-11 15:35     ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
@ 2012-06-11 15:52       ` Doug Evans
  2012-06-11 16:00         ` Joel Brobecker
  2012-06-21 20:20         ` Joel Brobecker
  2012-06-11 15:59       ` H.J. Lu
  1 sibling, 2 replies; 42+ messages in thread
From: Doug Evans @ 2012-06-11 15:52 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

On Mon, Jun 11, 2012 at 8:34 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello everyone,
>
> We're now a week past our tentative date for 7.5 branching.
> Can we have a list of issues still blocking the creation of that branch?
>
> I reviewed Jan's patches, and I am hopeful that we'll be able to
> move forward soon.
>
> I am not sure about Doug's items. Doug?
>
> Any other issues that have not been documented at our wiki page:
> http://sourceware.org/gdb/wiki/GDB_7.5_Release
> ?
>
> HJ, how far are you for x32?
>
> Thanks,
> --
> Joel

I've got a few days left on each item.

I haven't been able to test the psymtab symbol list reorg with
xcoffread.c or mdebugread.c.
IMO the patch can go in (the changes are similar to the changes to
stabsread.c, and if we can't test those targets they shouldn't hold
back progress on others), but what do others think?


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-11 15:35     ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
  2012-06-11 15:52       ` Doug Evans
@ 2012-06-11 15:59       ` H.J. Lu
  2012-06-11 16:11         ` Joel Brobecker
  1 sibling, 1 reply; 42+ messages in thread
From: H.J. Lu @ 2012-06-11 15:59 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches, Doug Evans

On Mon, Jun 11, 2012 at 8:34 AM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello everyone,
>
> We're now a week past our tentative date for 7.5 branching.
> Can we have a list of issues still blocking the creation of that branch?
>
> I reviewed Jan's patches, and I am hopeful that we'll be able to
> move forward soon.
>
> I am not sure about Doug's items. Doug?
>
> Any other issues that have not been documented at our wiki page:
> http://sourceware.org/gdb/wiki/GDB_7.5_Release
> ?
>
> HJ, how far are you for x32?
>

50% of x32 changes have been merged.  Mark and I have been
working on the rest.  What can I do to speed up the review
process?

Thanks.


-- 
H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-11 15:52       ` Doug Evans
@ 2012-06-11 16:00         ` Joel Brobecker
  2012-06-21 20:20         ` Joel Brobecker
  1 sibling, 0 replies; 42+ messages in thread
From: Joel Brobecker @ 2012-06-11 16:00 UTC (permalink / raw)
  To: Doug Evans; +Cc: gdb-patches

> I've got a few days left on each item.

OK, thanks for the status update, Doug. I think we have to wait for
Jan's changes as well anyway.

> I haven't been able to test the psymtab symbol list reorg with
> xcoffread.c or mdebugread.c.
> IMO the patch can go in (the changes are similar to the changes to
> stabsread.c, and if we can't test those targets they shouldn't hold
> back progress on others), but what do others think?

I should be able to give them some minimal testing, but I definitely
agree with that principle.

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-11 15:59       ` H.J. Lu
@ 2012-06-11 16:11         ` Joel Brobecker
  2012-06-11 16:20           ` H.J. Lu
  0 siblings, 1 reply; 42+ messages in thread
From: Joel Brobecker @ 2012-06-11 16:11 UTC (permalink / raw)
  To: H.J. Lu; +Cc: gdb-patches, Doug Evans

> 50% of x32 changes have been merged.  Mark and I have been
> working on the rest.  What can I do to speed up the review
> process?

Unfortunately, this is dependent on Mark's free time, so there isn't
much we can do, I think. I know this is fustrating, but this is
volunteer work, and all things considered, would it really be
the end of the world if some changes did not make it for 7.5,
but 7.6 instead (early 2013)?

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-11 16:11         ` Joel Brobecker
@ 2012-06-11 16:20           ` H.J. Lu
  0 siblings, 0 replies; 42+ messages in thread
From: H.J. Lu @ 2012-06-11 16:20 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches, Doug Evans

On Mon, Jun 11, 2012 at 9:11 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> 50% of x32 changes have been merged.  Mark and I have been
>> working on the rest.  What can I do to speed up the review
>> process?
>
> Unfortunately, this is dependent on Mark's free time, so there isn't
> much we can do, I think. I know this is fustrating, but this is
> volunteer work, and all things considered, would it really be
> the end of the world if some changes did not make it for 7.5,
> but 7.6 instead (early 2013)?
>

The current mainline doesn't work at all for x32. I'd like to get
the minimum x32 support into GDB 7.5.


-- 
H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Three weeks to branching (gdb 7.5 release)
  2012-06-11 14:58       ` Joel Brobecker
@ 2012-06-12 15:39         ` Maciej W. Rozycki
  0 siblings, 0 replies; 42+ messages in thread
From: Maciej W. Rozycki @ 2012-06-12 15:39 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Jan Kratochvil, gdb-patches

On Mon, 11 Jun 2012, Joel Brobecker wrote:

> >  I do understand the importance of the issues concerned by Jan of course, 
> > but I also feel like deferring the MIPS stuff for a month and likely more 
> > is going to get me distracted too much by something else,
> 
> Yeah, if the branch continues to be delayed much, we should go ahead
> with your changes, and adjust if some regressions are found.

 I think that if the outstanding issues have not been resolved by your 
deadline early next month, then perhaps it would make sense to branch 
anyway and let other development continue while the issues are being 
addressed on the branch (and ported to trunk as applicable).  What do you 
think?  Would it make things easier?  What's the usual practice?  At least 
this approach seems to work for binutils.

> > so given the circumstances may I kindly ask people to have a look into
> > my proposal and request for discussion about the generic parts of the
> > ISA bit changes as posted here:
> > 
> > http://sourceware.org/ml/gdb-patches/2012-05/msg00515.html
> 
> I will try myself, but may not be the best reviewer.

 I appreciate that, what can I do to make the review easier for you?

 I saw your replies, thanks.  I have been swamped with other stuff today 
and I am too tired already for my brain to produce any useful output, I'll 
try to follow up tomorrow.

  Maciej


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release))
  2012-06-11 13:42                     ` H.J. Lu
@ 2012-06-12 21:23                       ` Mark Kettenis
  2012-06-13 20:29                         ` x32 ABI Support (committed) Mark Kettenis
  0 siblings, 1 reply; 42+ messages in thread
From: Mark Kettenis @ 2012-06-12 21:23 UTC (permalink / raw)
  To: hjl.tools; +Cc: gdb-patches

> Date: Mon, 11 Jun 2012 06:42:32 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> 
> It works with the following patch.  Can you check it in?

Started working on that tonight but got sidetracked.  Will do my
utmost best to get this committed tomorrow.

> diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
> index 5b04505..9cc2e30 100644
> --- a/gdb/i386-tdep.c
> +++ b/gdb/i386-tdep.c
> @@ -2780,7 +2780,7 @@ i386_mmx_type (struct gdbarch *gdbarch)
>  /* Return the GDB type object for the "standard" data type of data in
>     register REGNUM.  */
> 
> -static struct type *
> +struct type *
>  i386_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
>  {
>    if (i386_mmx_regnum_p (gdbarch, regnum))
> diff --git a/gdb/i386-tdep.h b/gdb/i386-tdep.h
> index f297ae7..e1f7c44 100644
> --- a/gdb/i386-tdep.h
> +++ b/gdb/i386-tdep.h
> @@ -307,6 +315,7 @@ extern int i386_dword_regnum_p (struct gdbarch
> *gdbarch, int regnum);
>  extern int i386_xmm_regnum_p (struct gdbarch *gdbarch, int regnum);
>  extern int i386_ymm_regnum_p (struct gdbarch *gdbarch, int regnum);
> 
> +extern struct type *i386_pseudo_register_type (struct gdbarch *, int);
>  extern const char *i386_pseudo_register_name (struct gdbarch *gdbarch,
>  					      int regnum);
> 
> 


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (committed)
  2012-06-12 21:23                       ` Mark Kettenis
@ 2012-06-13 20:29                         ` Mark Kettenis
  2012-06-13 20:41                           ` Mark Kettenis
  0 siblings, 1 reply; 42+ messages in thread
From: Mark Kettenis @ 2012-06-13 20:29 UTC (permalink / raw)
  To: gdb-patches; +Cc: hjl.tools

> Date: Tue, 12 Jun 2012 23:23:28 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> 
> > Date: Mon, 11 Jun 2012 06:42:32 -0700
> > From: "H.J. Lu" <hjl.tools@gmail.com>
> > 
> > It works with the following patch.  Can you check it in?
> 
> Started working on that tonight but got sidetracked.  Will do my
> utmost best to get this committed tomorrow.

Ended up splitting out the Linux-specific bits from the generic bits.
Generic bits go first.

2012-06-13  Mark Kettenis  <kettenis@gnu.org>
	    H.J. Lu  <hongjiu.lu@intel.com>

	* i386-tdep.h (i386_pseudo_register_name): New prototype.
	* i386-tdep.c (i386_pseudo_register_name): Make public.
	* amd64-tdep.h (amd64_x32_init_abi): New prototype.
	* amd64-tdep.c (amd64_dword_names): Add "eip".
	(amd64_x32_pseudo_register_type): New function
	(amd64_x32_init_abi): New function.


Index: amd64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.c,v
retrieving revision 1.105
diff -u -p -r1.105 amd64-tdep.c
--- amd64-tdep.c	16 May 2012 14:35:02 -0000	1.105
+++ amd64-tdep.c	13 Jun 2012 20:24:54 -0000
@@ -258,7 +258,8 @@ static const char *amd64_word_names[] =
 static const char *amd64_dword_names[] =
 {
   "eax", "ebx", "ecx", "edx", "esi", "edi", "ebp", "esp", 
-  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d"
+  "r8d", "r9d", "r10d", "r11d", "r12d", "r13d", "r14d", "r15d",
+  "eip"
 };
 
 /* Return the name of register REGNUM.  */
@@ -2729,6 +2730,43 @@ amd64_init_abi (struct gdbarch_info info
   set_gdbarch_stap_parse_special_token (gdbarch,
 					i386_stap_parse_special_token);
 }
+\f
+
+static struct type *
+amd64_x32_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+
+  switch (regnum - tdep->eax_regnum)
+    {
+    case AMD64_RBP_REGNUM:	/* %ebp */
+    case AMD64_RSP_REGNUM:	/* %esp */
+      return builtin_type (gdbarch)->builtin_data_ptr;
+    case AMD64_RIP_REGNUM:	/* %eip */
+      return builtin_type (gdbarch)->builtin_func_ptr;
+    }
+
+  return i386_pseudo_register_type (gdbarch, regnum);
+}
+
+void
+amd64_x32_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+
+  amd64_init_abi (info, gdbarch);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_x32;
+  tdep->tdesc = tdesc;
+
+  tdep->num_dword_regs = 17;
+  set_tdesc_pseudo_register_type (gdbarch, amd64_x32_pseudo_register_type);
+
+  set_gdbarch_long_bit (gdbarch, 32);
+  set_gdbarch_ptr_bit (gdbarch, 32);
+}
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
 void _initialize_amd64_tdep (void);
Index: amd64-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/amd64-tdep.h,v
retrieving revision 1.21
diff -u -p -r1.21 amd64-tdep.h
--- amd64-tdep.h	4 Jan 2012 08:16:56 -0000	1.21
+++ amd64-tdep.h	13 Jun 2012 20:24:54 -0000
@@ -80,6 +80,8 @@ extern void amd64_displaced_step_fixup (
 					struct regcache *regs);
 
 extern void amd64_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
+extern void amd64_x32_init_abi (struct gdbarch_info info,
+				struct gdbarch *gdbarch);
 
 /* Fill register REGNUM in REGCACHE with the appropriate
    floating-point or SSE register value from *FXSAVE.  If REGNUM is
Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.351
diff -u -p -r1.351 i386-tdep.c
--- i386-tdep.c	18 May 2012 21:02:48 -0000	1.351
+++ i386-tdep.c	13 Jun 2012 20:24:57 -0000
@@ -2780,7 +2780,7 @@ i386_mmx_type (struct gdbarch *gdbarch)
 /* Return the GDB type object for the "standard" data type of data in
    register REGNUM.  */
 
-static struct type *
+struct type *
 i386_pseudo_register_type (struct gdbarch *gdbarch, int regnum)
 {
   if (i386_mmx_regnum_p (gdbarch, regnum))
Index: i386-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.h,v
retrieving revision 1.78
diff -u -p -r1.78 i386-tdep.h
--- i386-tdep.h	27 Apr 2012 20:47:54 -0000	1.78
+++ i386-tdep.h	13 Jun 2012 20:24:57 -0000
@@ -309,6 +309,8 @@ extern int i386_ymm_regnum_p (struct gdb
 
 extern const char *i386_pseudo_register_name (struct gdbarch *gdbarch,
 					      int regnum);
+extern struct type *i386_pseudo_register_type (struct gdbarch *gdbarch,
+					       int regnum);
 
 extern void i386_pseudo_register_read_into_value (struct gdbarch *gdbarch,
 						  struct regcache *regcache,


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: x32 ABI Support (committed)
  2012-06-13 20:29                         ` x32 ABI Support (committed) Mark Kettenis
@ 2012-06-13 20:41                           ` Mark Kettenis
  0 siblings, 0 replies; 42+ messages in thread
From: Mark Kettenis @ 2012-06-13 20:41 UTC (permalink / raw)
  To: gdb-patches, hjl.tools; +Cc: hjl.tools

> Date: Wed, 13 Jun 2012 22:29:36 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> 
> > Date: Tue, 12 Jun 2012 23:23:28 +0200 (CEST)
> > From: Mark Kettenis <mark.kettenis@xs4all.nl>
> > 
> > > Date: Mon, 11 Jun 2012 06:42:32 -0700
> > > From: "H.J. Lu" <hjl.tools@gmail.com>
> > > 
> > > It works with the following patch.  Can you check it in?
> > 
> > Started working on that tonight but got sidetracked.  Will do my
> > utmost best to get this committed tomorrow.
> 
> Ended up splitting out the Linux-specific bits from the generic bits.
> Generic bits go first.

And here are the Linux-specific bits.

 2012-06-13  Mark Kettenis  <kettenis@gnu.org>
 	    H.J. Lu  <hongjiu.lu@intel.com>
 
	* amd64-linux-tdep.c (amd64_linux_init_abi_common): New function.
	Move bits common to both the classic LP64 and the new x32 ILP32
	ABI here.
	(amd64_linux_init_abi): Call amd64_linux_init_abi_common.
	(amd64_x32_linux_init_abi): New function.
	(_initialize_amd64_linux_tdep): Register osabi for bfd_mach_x64_32
	subtype.

Index: amd64-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-linux-tdep.c,v
retrieving revision 1.51
diff -u -p -r1.51 amd64-linux-tdep.c
--- amd64-linux-tdep.c	24 May 2012 16:39:06 -0000	1.51
+++ amd64-linux-tdep.c	13 Jun 2012 20:33:34 -0000
@@ -1288,41 +1288,12 @@ amd64_linux_core_read_description (struc
 }
 
 static void
-amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+amd64_linux_init_abi_common(struct gdbarch_info info, struct gdbarch *gdbarch)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
-  const struct target_desc *tdesc = info.target_desc;
-  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
-  const struct tdesc_feature *feature;
-  int valid_p;
-
-  gdb_assert (tdesc_data);
 
   linux_init_abi (info, gdbarch);
 
-  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
-  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
-  tdep->sizeof_gregset = 27 * 8;
-
-  amd64_init_abi (info, gdbarch);
-
-  /* Reserve a number for orig_rax.  */
-  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
-
-  if (! tdesc_has_registers (tdesc))
-    tdesc = tdesc_amd64_linux;
-  tdep->tdesc = tdesc;
-
-  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
-  if (feature == NULL)
-    return;
-
-  valid_p = tdesc_numbered_register (feature, tdesc_data,
-				     AMD64_LINUX_ORIG_RAX_REGNUM,
-				     "orig_rax");
-  if (!valid_p)
-    return;
-
   tdep->sigtramp_p = amd64_linux_sigtramp_p;
   tdep->sigcontext_addr = amd64_linux_sigcontext_addr;
   tdep->sc_reg_offset = amd64_linux_sc_reg_offset;
@@ -1330,10 +1301,6 @@ amd64_linux_init_abi (struct gdbarch_inf
 
   tdep->xsave_xcr0_offset = I386_LINUX_XSAVE_XCR0_OFFSET;
 
-  /* GNU/Linux uses SVR4-style shared libraries.  */
-  set_solib_svr4_fetch_link_map_offsets
-    (gdbarch, svr4_lp64_fetch_link_map_offsets);
-
   /* Add the %orig_rax register used for syscall restarting.  */
   set_gdbarch_write_pc (gdbarch, amd64_linux_write_pc);
 
@@ -1543,6 +1510,88 @@ amd64_linux_init_abi (struct gdbarch_inf
 
   tdep->i386_syscall_record = amd64_linux_syscall_record;
 }
+
+static void
+amd64_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
+  const struct tdesc_feature *feature;
+  int valid_p;
+
+  gdb_assert (tdesc_data);
+
+  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
+  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
+  tdep->sizeof_gregset = 27 * 8;
+
+  amd64_init_abi (info, gdbarch);
+
+  /* Reserve a number for orig_rax.  */
+  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_amd64_linux;
+  tdep->tdesc = tdesc;
+
+  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
+  if (feature == NULL)
+    return;
+
+  valid_p = tdesc_numbered_register (feature, tdesc_data,
+				     AMD64_LINUX_ORIG_RAX_REGNUM,
+				     "orig_rax");
+  if (!valid_p)
+    return;
+
+  amd64_linux_init_abi_common (info, gdbarch);
+
+  /* GNU/Linux uses SVR4-style shared libraries.  */
+  set_solib_svr4_fetch_link_map_offsets
+    (gdbarch, svr4_lp64_fetch_link_map_offsets);
+}
+
+static void
+amd64_x32_linux_init_abi(struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
+  const struct target_desc *tdesc = info.target_desc;
+  struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
+  const struct tdesc_feature *feature;
+  int valid_p;
+
+  gdb_assert (tdesc_data);
+
+  tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
+  tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
+  tdep->sizeof_gregset = 27 * 8;
+
+  amd64_x32_init_abi (info, gdbarch);
+
+  /* Reserve a number for orig_rax.  */
+  set_gdbarch_num_regs (gdbarch, AMD64_LINUX_NUM_REGS);
+
+  if (! tdesc_has_registers (tdesc))
+    tdesc = tdesc_x32_linux;
+  tdep->tdesc = tdesc;
+
+  feature = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.linux");
+  if (feature == NULL)
+    return;
+
+  valid_p = tdesc_numbered_register (feature, tdesc_data,
+				     AMD64_LINUX_ORIG_RAX_REGNUM,
+				     "orig_rax");
+  if (!valid_p)
+    return;
+
+  amd64_linux_init_abi_common (info, gdbarch);
+
+  /* GNU/Linux uses SVR4-style shared libraries.  */
+  set_solib_svr4_fetch_link_map_offsets
+    (gdbarch, svr4_ilp32_fetch_link_map_offsets);
+}
 \f
 
 /* Provide a prototype to silence -Wmissing-prototypes.  */
@@ -1553,6 +1602,8 @@ _initialize_amd64_linux_tdep (void)
 {
   gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x86_64,
 			  GDB_OSABI_LINUX, amd64_linux_init_abi);
+  gdbarch_register_osabi (bfd_arch_i386, bfd_mach_x64_32,
+			  GDB_OSABI_LINUX, amd64_x32_linux_init_abi);
 
   /* Initialize the Linux target description.  */
   initialize_tdesc_amd64_linux ();


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-11 15:52       ` Doug Evans
  2012-06-11 16:00         ` Joel Brobecker
@ 2012-06-21 20:20         ` Joel Brobecker
  2012-06-21 20:25           ` Doug Evans
  2012-06-22 14:47           ` Jan Kratochvil
  1 sibling, 2 replies; 42+ messages in thread
From: Joel Brobecker @ 2012-06-21 20:20 UTC (permalink / raw)
  To: Doug Evans, Jan Kratochvil; +Cc: gdb-patches

Hello everyone,

We are now at slightly over 2 weeks past our tentative branching
time. I was wondering if we are getting closer to fixing all
the issues marked as blocking?

Given that we have two contributions that were tagged as maybe too
risky for 7.5, it would be nice to be able to branch sooner rather
than later.

Worse case scenario, if we don't think we'll be ready soon, what
we can do is branch now, and fix any remaining item on the branch.
But I don't want to make that decision if we think we'll be able
to branch soon.

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-21 20:20         ` Joel Brobecker
@ 2012-06-21 20:25           ` Doug Evans
  2012-06-22 14:47           ` Jan Kratochvil
  1 sibling, 0 replies; 42+ messages in thread
From: Doug Evans @ 2012-06-21 20:25 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Jan Kratochvil, gdb-patches

On Thu, Jun 21, 2012 at 1:20 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hello everyone,
>
> We are now at slightly over 2 weeks past our tentative branching
> time. I was wondering if we are getting closer to fixing all
> the issues marked as blocking?
>
> Given that we have two contributions that were tagged as maybe too
> risky for 7.5, it would be nice to be able to branch sooner rather
> than later.
>
> Worse case scenario, if we don't think we'll be ready soon, what
> we can do is branch now, and fix any remaining item on the branch.
> But I don't want to make that decision if we think we'll be able
> to branch soon.

I don't mind branching whenever.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-21 20:20         ` Joel Brobecker
  2012-06-21 20:25           ` Doug Evans
@ 2012-06-22 14:47           ` Jan Kratochvil
  2012-06-22 16:32             ` Joel Brobecker
  1 sibling, 1 reply; 42+ messages in thread
From: Jan Kratochvil @ 2012-06-22 14:47 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Doug Evans, gdb-patches

On Thu, 21 Jun 2012 22:20:23 +0200, Joel Brobecker wrote:
> We are now at slightly over 2 weeks past our tentative branching
> time. I was wondering if we are getting closer to fixing all
> the issues marked as blocking?

Added two patches but those seem to be done although still discussed with Eli:

  * [Jan] auto-load safe-path: Permit shell wildcards
    http://sourceware.org/ml/gdb-patches/2012-06/msg00700.html

  * [Jan] -iex and -ix: Execute them _after_ gdbinits
    http://sourceware.org/ml/gdb-patches/2012-06/msg00549.html

A week seems OK to me.


Regards,
Jan


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-22 14:47           ` Jan Kratochvil
@ 2012-06-22 16:32             ` Joel Brobecker
  2012-06-22 16:41               ` Jan Kratochvil
  2012-06-22 16:42               ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") H.J. Lu
  0 siblings, 2 replies; 42+ messages in thread
From: Joel Brobecker @ 2012-06-22 16:32 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Doug Evans, gdb-patches

> Added two patches but those seem to be done although still discussed with Eli:
> 
>   * [Jan] auto-load safe-path: Permit shell wildcards
>     http://sourceware.org/ml/gdb-patches/2012-06/msg00700.html

Do I understand correctly that the first patch would have no impact
if we adopted the (rather-large-but-what-can-we-do) gnulib import?
If that's correct, we could move this patch off the critical path.

>   * [Jan] -iex and -ix: Execute them _after_ gdbinits
>     http://sourceware.org/ml/gdb-patches/2012-06/msg00549.html

> A week seems OK to me.

OK, let's see where we are at on Wed.

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-22 16:32             ` Joel Brobecker
@ 2012-06-22 16:41               ` Jan Kratochvil
  2012-06-22 17:38                 ` Branching time + 1 week Tom Tromey
  2012-06-22 20:31                 ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
  2012-06-22 16:42               ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") H.J. Lu
  1 sibling, 2 replies; 42+ messages in thread
From: Jan Kratochvil @ 2012-06-22 16:41 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Doug Evans, gdb-patches

On Fri, 22 Jun 2012 18:32:24 +0200, Joel Brobecker wrote:
> > Added two patches but those seem to be done although still discussed with Eli:
> > 
> >   * [Jan] auto-load safe-path: Permit shell wildcards
> >     http://sourceware.org/ml/gdb-patches/2012-06/msg00700.html
> 
> Do I understand correctly that the first patch would have no impact
> if we adopted the (rather-large-but-what-can-we-do) gnulib import?
> If that's correct, we could move this patch off the critical path.

There are:
Re: [patch 1/2] auto-load safe-path: Permit shell wildcards
http://sourceware.org/ml/gdb-patches/2012-06/msg00700.html
[patch 2/2] [mingw+non-GNU?] gnulib fnmatch for libiberty/ FNM_FILE_NAME bugs
http://sourceware.org/ml/gdb-patches/2012-06/msg00558.html

[patch 1/2] works perfectly fine on GNU/Linux without [patch 2/2].
[patch 2/2] has no effect anywhere without [patch 1/2].

But the new functionality of [patch 1/2] behaves incorrectly on non-GNU/Linux
systems without [patch 2/2].

TBH I do not think auto-load safe-path functionality is of much concern on
non-GNU/Linux systems at all but to keep all correct...

Also before checking-in [patch 2/2] I am going to update gnulib files as
[obv] to separate gnulib update vs. gnulib addition of fnmatch-gnu module.
I could add fnmatch-gnu from a several months old gnulib snapshot but that
sems incorrect to me.  gnulib update also seems safe enough to me (WDYT?).


Thanks,
Jan


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-22 16:32             ` Joel Brobecker
  2012-06-22 16:41               ` Jan Kratochvil
@ 2012-06-22 16:42               ` H.J. Lu
  1 sibling, 0 replies; 42+ messages in thread
From: H.J. Lu @ 2012-06-22 16:42 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Jan Kratochvil, Doug Evans, gdb-patches

On Fri, Jun 22, 2012 at 9:32 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Added two patches but those seem to be done although still discussed with Eli:
>>
>>   * [Jan] auto-load safe-path: Permit shell wildcards
>>     http://sourceware.org/ml/gdb-patches/2012-06/msg00700.html
>
> Do I understand correctly that the first patch would have no impact
> if we adopted the (rather-large-but-what-can-we-do) gnulib import?
> If that's correct, we could move this patch off the critical path.
>
>>   * [Jan] -iex and -ix: Execute them _after_ gdbinits
>>     http://sourceware.org/ml/gdb-patches/2012-06/msg00549.html
>
>> A week seems OK to me.
>
> OK, let's see where we are at on Wed.
>

There are 3 small x32 patches pending review:

http://sourceware.org/ml/gdb-patches/2012-06/msg00664.html
http://sourceware.org/ml/gdb-patches/2012-06/msg00667.html
http://sourceware.org/ml/gdb-patches/2012-06/msg00666.html


-- 
H.J.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week
  2012-06-22 16:41               ` Jan Kratochvil
@ 2012-06-22 17:38                 ` Tom Tromey
  2012-06-22 20:31                 ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
  1 sibling, 0 replies; 42+ messages in thread
From: Tom Tromey @ 2012-06-22 17:38 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Joel Brobecker, Doug Evans, gdb-patches

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> gnulib update also seems safe enough to me (WDYT?).

I think so.

Tom


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)")
  2012-06-22 16:41               ` Jan Kratochvil
  2012-06-22 17:38                 ` Branching time + 1 week Tom Tromey
@ 2012-06-22 20:31                 ` Joel Brobecker
  2012-06-24  9:14                   ` [commit] gnulib update [Re: Branching time + 1 week] Jan Kratochvil
  1 sibling, 1 reply; 42+ messages in thread
From: Joel Brobecker @ 2012-06-22 20:31 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: Doug Evans, gdb-patches

> Also before checking-in [patch 2/2] I am going to update gnulib files as
> [obv] to separate gnulib update vs. gnulib addition of fnmatch-gnu module.
> I could add fnmatch-gnu from a several months old gnulib snapshot but that
> sems incorrect to me.  gnulib update also seems safe enough to me (WDYT?).

I would imagine that it's fairly safe, but we are about branch,
so we have little time to find any possible regression that might
be introduced by the update. If we are going to do the gnulib
update, let's do it right away.

-- 
Joel


^ permalink raw reply	[flat|nested] 42+ messages in thread

* [commit] gnulib update  [Re: Branching time + 1 week]
  2012-06-22 20:31                 ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
@ 2012-06-24  9:14                   ` Jan Kratochvil
  0 siblings, 0 replies; 42+ messages in thread
From: Jan Kratochvil @ 2012-06-24  9:14 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Doug Evans, gdb-patches

On Fri, 22 Jun 2012 22:30:48 +0200, Joel Brobecker wrote:
> > Also before checking-in [patch 2/2] I am going to update gnulib files as
> > [obv] to separate gnulib update vs. gnulib addition of fnmatch-gnu module.
> > I could add fnmatch-gnu from a several months old gnulib snapshot but that
> > sems incorrect to me.  gnulib update also seems safe enough to me (WDYT?).
> 
> I would imagine that it's fairly safe, but we are about branch,
> so we have little time to find any possible regression that might
> be introduced by the update. If we are going to do the gnulib
> update, let's do it right away.

Done.

No regressions on {x86_64,x86_64-m32,i686}-fedorarawhide-linux-gnu.


Jan


http://sourceware.org/ml/gdb-cvs/2012-06/msg00174.html

--- src/gdb/ChangeLog	2012/06/24 07:28:06	1.14393
+++ src/gdb/ChangeLog	2012/06/24 09:12:31	1.14394
@@ -1,3 +1,15 @@
+2012-06-24  Jan Kratochvil  <jan.kratochvil@redhat.com>
+
+	Update gnulib to GIT commit a39f53ccb70a613e647e1019fb4c63645220267e.
+	* gnulib/config.in: Regenerate.
+	* gnulib/configure: Likewise.
+	* gnulib/import/m4/extensions.m4: Update it.
+	* gnulib/import/m4/gnulib-common.m4: Likewise.
+	* gnulib/import/m4/memmem.m4: Likewise.
+	* gnulib/import/m4/mmap-anon.m4: Likewise.
+	* gnulib/import/m4/multiarch.m4: Likewise.
+	* gnulib/import/stdint.in.h: Likewise.
+
 2012-06-24  Yao Qi  <yao@codesourcery.com>
 
 	* corefile.c (write_memory_with_notification): New.
--- src/gdb/gnulib/config.in	2012/04/19 19:34:51	1.1
+++ src/gdb/gnulib/config.in	2012/06/24 09:12:32	1.2
@@ -218,7 +218,8 @@
 #undef _MINIX
 
 /* The _Noreturn keyword of C11.  */
-#ifndef _Noreturn
+#if ! (defined _Noreturn \
+       || (defined __STDC_VERSION__ && 201112 <= __STDC_VERSION__))
 # if (3 <= __GNUC__ || (__GNUC__ == 2 && 8 <= __GNUC_MINOR__) \
       || 0x5110 <= __SUNPRO_C)
 #  define _Noreturn __attribute__ ((__noreturn__))
@@ -244,7 +245,7 @@
 #ifndef _ALL_SOURCE
 # undef _ALL_SOURCE
 #endif
-/* Enable general extensions on MacOS X.  */
+/* Enable general extensions on Mac OS X.  */
 #ifndef _DARWIN_C_SOURCE
 # undef _DARWIN_C_SOURCE
 #endif
@@ -269,7 +270,7 @@
 /* Work around a bug in Apple GCC 4.0.1 build 5465: In C99 mode, it supports
    the ISO C 99 semantics of 'extern inline' (unlike the GNU C semantics of
    earlier versions), but does not display it by setting __GNUC_STDC_INLINE__.
-   __APPLE__ && __MACH__ test for MacOS X.
+   __APPLE__ && __MACH__ test for Mac OS X.
    __APPLE_CC__ tests for the Apple compiler and its version.
    __STDC_VERSION__ tests for the C99 mode.  */
 #if defined __APPLE__ && defined __MACH__ && __APPLE_CC__ >= 5465 && !defined __cplusplus && __STDC_VERSION__ >= 199901L && !defined __GNUC_STDC_INLINE__
--- src/gdb/gnulib/configure	2012/04/19 19:34:51	1.1
+++ src/gdb/gnulib/configure	2012/06/24 09:12:32	1.2
@@ -6099,12 +6099,12 @@
 
 #include <sys/mman.h>
 #ifdef MAP_ANONYMOUS
-    I cant identify this map
+    I cannot identify this map
 #endif
 
 _ACEOF
 if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
-  $EGREP "I cant identify this map" >/dev/null 2>&1; then :
+  $EGREP "I cannot identify this map" >/dev/null 2>&1; then :
   gl_have_mmap_anonymous=yes
 fi
 rm -f conftest*
@@ -6115,12 +6115,12 @@
 
 #include <sys/mman.h>
 #ifdef MAP_ANON
-    I cant identify this map
+    I cannot identify this map
 #endif
 
 _ACEOF
 if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
-  $EGREP "I cant identify this map" >/dev/null 2>&1; then :
+  $EGREP "I cannot identify this map" >/dev/null 2>&1; then :
 
 $as_echo "#define MAP_ANONYMOUS MAP_ANON" >>confdefs.h
 
@@ -6315,7 +6315,7 @@
 _ACEOF
 if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
   $EGREP "Lucky user" >/dev/null 2>&1; then :
-  gl_cv_func_memmem_works_always=yes
+  gl_cv_func_memmem_works_always="guessing yes"
 else
   gl_cv_func_memmem_works_always="guessing no"
 fi
@@ -6363,9 +6363,12 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gl_cv_func_memmem_works_always" >&5
 $as_echo "$gl_cv_func_memmem_works_always" >&6; }
-    if test "$gl_cv_func_memmem_works_always" != yes; then
-      REPLACE_MEMMEM=1
-    fi
+    case "$gl_cv_func_memmem_works_always" in
+      *yes) ;;
+      *)
+        REPLACE_MEMMEM=1
+        ;;
+    esac
   fi
   :
 
@@ -6912,7 +6915,7 @@
 _ACEOF
 if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
   $EGREP "Lucky user" >/dev/null 2>&1; then :
-  gl_cv_func_memmem_works_fast=yes
+  gl_cv_func_memmem_works_fast="guessing yes"
 else
   gl_cv_func_memmem_works_fast="guessing no"
 fi
@@ -6970,9 +6973,12 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gl_cv_func_memmem_works_fast" >&5
 $as_echo "$gl_cv_func_memmem_works_fast" >&6; }
-    if test "$gl_cv_func_memmem_works_fast" != yes; then
-      REPLACE_MEMMEM=1
-    fi
+    case "$gl_cv_func_memmem_works_fast" in
+      *yes) ;;
+      *)
+        REPLACE_MEMMEM=1
+        ;;
+    esac
   fi
 
 if test $HAVE_MEMMEM = 0 || test $REPLACE_MEMMEM = 1; then
@@ -7046,7 +7052,7 @@
 _ACEOF
 if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
   $EGREP "Lucky user" >/dev/null 2>&1; then :
-  gl_cv_func_memmem_works_always=yes
+  gl_cv_func_memmem_works_always="guessing yes"
 else
   gl_cv_func_memmem_works_always="guessing no"
 fi
@@ -7094,9 +7100,12 @@
 fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gl_cv_func_memmem_works_always" >&5
 $as_echo "$gl_cv_func_memmem_works_always" >&6; }
-    if test "$gl_cv_func_memmem_works_always" != yes; then
-      REPLACE_MEMMEM=1
-    fi
+    case "$gl_cv_func_memmem_works_always" in
+      *yes) ;;
+      *)
+        REPLACE_MEMMEM=1
+        ;;
+    esac
   fi
   :
 
--- src/gdb/gnulib/import/stdint.in.h	2012/04/19 15:27:49	1.1
+++ src/gdb/gnulib/import/stdint.in.h	2012/06/24 09:12:32	1.2
@@ -83,14 +83,15 @@
 /* <sys/types.h> defines some of the stdint.h types as well, on glibc,
    IRIX 6.5, and OpenBSD 3.8 (via <machine/types.h>).
    AIX 5.2 <sys/types.h> isn't needed and causes troubles.
-   MacOS X 10.4.6 <sys/types.h> includes <stdint.h> (which is us), but
+   Mac OS X 10.4.6 <sys/types.h> includes <stdint.h> (which is us), but
    relies on the system <stdint.h> definitions, so include
    <sys/types.h> after @NEXT_STDINT_H@.  */
 #if @HAVE_SYS_TYPES_H@ && ! defined _AIX
 # include <sys/types.h>
 #endif
 
-/* Get LONG_MIN, LONG_MAX, ULONG_MAX.  */
+/* Get SCHAR_MIN, SCHAR_MAX, UCHAR_MAX, INT_MIN, INT_MAX,
+   LONG_MIN, LONG_MAX, ULONG_MAX.  */
 #include <limits.h>
 
 #if @HAVE_INTTYPES_H@
@@ -246,8 +247,9 @@
 
 /* Here we assume a standard architecture where the hardware integer
    types have 8, 16, 32, optionally 64 bits. Therefore the fastN_t types
-   are taken from the same list of types.  Assume that 'long int'
-   is fast enough for all narrower integers.  */
+   are taken from the same list of types.  The following code normally
+   uses types consistent with glibc, as that lessens the chance of
+   incompatibility with older GNU hosts.  */
 
 #undef int_fast8_t
 #undef uint_fast8_t
@@ -257,12 +259,21 @@
 #undef uint_fast32_t
 #undef int_fast64_t
 #undef uint_fast64_t
-typedef long int gl_int_fast8_t;
-typedef unsigned long int gl_uint_fast8_t;
-typedef long int gl_int_fast16_t;
-typedef unsigned long int gl_uint_fast16_t;
+typedef signed char gl_int_fast8_t;
+typedef unsigned char gl_uint_fast8_t;
+
+#ifdef __sun
+/* Define types compatible with SunOS 5.10, so that code compiled under
+   earlier SunOS versions works with code compiled under SunOS 5.10.  */
+typedef int gl_int_fast32_t;
+typedef unsigned int gl_uint_fast32_t;
+#else
 typedef long int gl_int_fast32_t;
 typedef unsigned long int gl_uint_fast32_t;
+#endif
+typedef gl_int_fast32_t gl_int_fast16_t;
+typedef gl_uint_fast32_t gl_uint_fast16_t;
+
 #define int_fast8_t gl_int_fast8_t
 #define uint_fast8_t gl_uint_fast8_t
 #define int_fast16_t gl_int_fast16_t
@@ -418,23 +429,29 @@
 #undef INT_FAST8_MIN
 #undef INT_FAST8_MAX
 #undef UINT_FAST8_MAX
-#define INT_FAST8_MIN  LONG_MIN
-#define INT_FAST8_MAX  LONG_MAX
-#define UINT_FAST8_MAX  ULONG_MAX
+#define INT_FAST8_MIN  SCHAR_MIN
+#define INT_FAST8_MAX  SCHAR_MAX
+#define UINT_FAST8_MAX  UCHAR_MAX
 
 #undef INT_FAST16_MIN
 #undef INT_FAST16_MAX
 #undef UINT_FAST16_MAX
-#define INT_FAST16_MIN  LONG_MIN
-#define INT_FAST16_MAX  LONG_MAX
-#define UINT_FAST16_MAX  ULONG_MAX
+#define INT_FAST16_MIN  INT_FAST32_MIN
+#define INT_FAST16_MAX  INT_FAST32_MAX
+#define UINT_FAST16_MAX  UINT_FAST32_MAX
 
 #undef INT_FAST32_MIN
 #undef INT_FAST32_MAX
 #undef UINT_FAST32_MAX
-#define INT_FAST32_MIN  LONG_MIN
-#define INT_FAST32_MAX  LONG_MAX
-#define UINT_FAST32_MAX  ULONG_MAX
+#ifdef __sun
+# define INT_FAST32_MIN  INT_MIN
+# define INT_FAST32_MAX  INT_MAX
+# define UINT_FAST32_MAX  UINT_MAX
+#else
+# define INT_FAST32_MIN  LONG_MIN
+# define INT_FAST32_MAX  LONG_MAX
+# define UINT_FAST32_MAX  ULONG_MAX
+#endif
 
 #undef INT_FAST64_MIN
 #undef INT_FAST64_MAX
--- src/gdb/gnulib/import/m4/extensions.m4	2012/04/19 15:27:51	1.1
+++ src/gdb/gnulib/import/m4/extensions.m4	2012/06/24 09:12:33	1.2
@@ -1,4 +1,4 @@
-# serial 11  -*- Autoconf -*-
+# serial 12  -*- Autoconf -*-
 # Enable extensions on systems that normally disable them.
 
 # Copyright (C) 2003, 2006-2012 Free Software Foundation, Inc.
@@ -67,7 +67,7 @@
 #ifndef _ALL_SOURCE
 # undef _ALL_SOURCE
 #endif
-/* Enable general extensions on MacOS X.  */
+/* Enable general extensions on Mac OS X.  */
 #ifndef _DARWIN_C_SOURCE
 # undef _DARWIN_C_SOURCE
 #endif
--- src/gdb/gnulib/import/m4/gnulib-common.m4	2012/04/19 15:27:51	1.1
+++ src/gdb/gnulib/import/m4/gnulib-common.m4	2012/06/24 09:12:33	1.2
@@ -1,4 +1,4 @@
-# gnulib-common.m4 serial 32
+# gnulib-common.m4 serial 33
 dnl Copyright (C) 2007-2012 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -14,7 +14,8 @@
 AC_DEFUN([gl_COMMON_BODY], [
   AH_VERBATIM([_Noreturn],
 [/* The _Noreturn keyword of C11.  */
-#ifndef _Noreturn
+#if ! (defined _Noreturn \
+       || (defined __STDC_VERSION__ && 201112 <= __STDC_VERSION__))
 # if (3 <= __GNUC__ || (__GNUC__ == 2 && 8 <= __GNUC_MINOR__) \
       || 0x5110 <= __SUNPRO_C)
 #  define _Noreturn __attribute__ ((__noreturn__))
@@ -29,7 +30,7 @@
 [/* Work around a bug in Apple GCC 4.0.1 build 5465: In C99 mode, it supports
    the ISO C 99 semantics of 'extern inline' (unlike the GNU C semantics of
    earlier versions), but does not display it by setting __GNUC_STDC_INLINE__.
-   __APPLE__ && __MACH__ test for MacOS X.
+   __APPLE__ && __MACH__ test for Mac OS X.
    __APPLE_CC__ tests for the Apple compiler and its version.
    __STDC_VERSION__ tests for the C99 mode.  */
 #if defined __APPLE__ && defined __MACH__ && __APPLE_CC__ >= 5465 && !defined __cplusplus && __STDC_VERSION__ >= 199901L && !defined __GNUC_STDC_INLINE__
--- src/gdb/gnulib/import/m4/memmem.m4	2012/04/19 15:27:51	1.1
+++ src/gdb/gnulib/import/m4/memmem.m4	2012/06/24 09:12:33	1.2
@@ -1,4 +1,4 @@
-# memmem.m4 serial 23
+# memmem.m4 serial 24
 dnl Copyright (C) 2002-2004, 2007-2012 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -67,13 +67,16 @@
   Lucky user
 #endif
            ],
-           [gl_cv_func_memmem_works_always=yes],
+           [gl_cv_func_memmem_works_always="guessing yes"],
            [gl_cv_func_memmem_works_always="guessing no"])
         ])
       ])
-    if test "$gl_cv_func_memmem_works_always" != yes; then
-      REPLACE_MEMMEM=1
-    fi
+    case "$gl_cv_func_memmem_works_always" in
+      *yes) ;;
+      *)
+        REPLACE_MEMMEM=1
+        ;;
+    esac
   fi
   gl_PREREQ_MEMMEM
 ]) # gl_FUNC_MEMMEM_SIMPLE
@@ -131,13 +134,16 @@
  #endif
 #endif
            ],
-           [gl_cv_func_memmem_works_fast=yes],
+           [gl_cv_func_memmem_works_fast="guessing yes"],
            [gl_cv_func_memmem_works_fast="guessing no"])
         ])
       ])
-    if test "$gl_cv_func_memmem_works_fast" != yes; then
-      REPLACE_MEMMEM=1
-    fi
+    case "$gl_cv_func_memmem_works_fast" in
+      *yes) ;;
+      *)
+        REPLACE_MEMMEM=1
+        ;;
+    esac
   fi
 ]) # gl_FUNC_MEMMEM
 
--- src/gdb/gnulib/import/m4/mmap-anon.m4	2012/04/19 15:27:51	1.1
+++ src/gdb/gnulib/import/m4/mmap-anon.m4	2012/06/24 09:12:33	1.2
@@ -1,4 +1,4 @@
-# mmap-anon.m4 serial 9
+# mmap-anon.m4 serial 10
 dnl Copyright (C) 2005, 2007, 2009-2012 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -9,7 +9,7 @@
 # - On Linux, AIX, OSF/1, Solaris, Cygwin, Interix, Haiku, both MAP_ANONYMOUS
 #   and MAP_ANON exist and have the same value.
 # - On HP-UX, only MAP_ANONYMOUS exists.
-# - On MacOS X, FreeBSD, NetBSD, OpenBSD, only MAP_ANON exists.
+# - On Mac OS X, FreeBSD, NetBSD, OpenBSD, only MAP_ANON exists.
 # - On IRIX, neither exists, and a file descriptor opened to /dev/zero must be
 #   used.
 
@@ -27,18 +27,18 @@
   gl_have_mmap_anonymous=no
   if test $gl_have_mmap = yes; then
     AC_MSG_CHECKING([for MAP_ANONYMOUS])
-    AC_EGREP_CPP([I cant identify this map], [
+    AC_EGREP_CPP([I cannot identify this map], [
 #include <sys/mman.h>
 #ifdef MAP_ANONYMOUS
-    I cant identify this map
+    I cannot identify this map
 #endif
 ],
       [gl_have_mmap_anonymous=yes])
     if test $gl_have_mmap_anonymous != yes; then
-      AC_EGREP_CPP([I cant identify this map], [
+      AC_EGREP_CPP([I cannot identify this map], [
 #include <sys/mman.h>
 #ifdef MAP_ANON
-    I cant identify this map
+    I cannot identify this map
 #endif
 ],
         [AC_DEFINE([MAP_ANONYMOUS], [MAP_ANON],
--- src/gdb/gnulib/import/m4/multiarch.m4	2012/04/19 15:27:51	1.1
+++ src/gdb/gnulib/import/m4/multiarch.m4	2012/06/24 09:12:33	1.2
@@ -1,4 +1,4 @@
-# multiarch.m4 serial 6
+# multiarch.m4 serial 7
 dnl Copyright (C) 2008-2012 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -6,7 +6,7 @@
 
 # Determine whether the compiler is or may be producing universal binaries.
 #
-# On MacOS X 10.5 and later systems, the user can create libraries and
+# On Mac OS X 10.5 and later systems, the user can create libraries and
 # executables that work on multiple system types--known as "fat" or
 # "universal" binaries--by specifying multiple '-arch' options to the
 # compiler but only a single '-arch' option to the preprocessor.  Like


^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2012-06-24  9:14 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-11 18:17 Three weeks to branching (gdb 7.5 release) Joel Brobecker
2012-05-11 18:43 ` H.J. Lu
2012-05-14 14:45   ` Joel Brobecker
2012-05-20 15:40   ` H.J. Lu
2012-05-20 20:44     ` Mark Kettenis
2012-05-20 21:25       ` H.J. Lu
2012-05-20 21:39         ` Mark Kettenis
2012-05-20 22:49           ` H.J. Lu
2012-05-25 16:52             ` H.J. Lu
2012-05-28 20:26             ` x32 ABI Support (was Re: Three weeks to branching (gdb 7.5 release)) Mark Kettenis
2012-05-28 21:18               ` H.J. Lu
2012-05-31 18:18                 ` H.J. Lu
2012-06-05 12:58                   ` H.J. Lu
2012-06-05 13:16                     ` Mark Kettenis
2012-06-09 14:30                       ` H.J. Lu
2012-06-10 21:52                   ` Mark Kettenis
2012-06-11 13:42                     ` H.J. Lu
2012-06-12 21:23                       ` Mark Kettenis
2012-06-13 20:29                         ` x32 ABI Support (committed) Mark Kettenis
2012-06-13 20:41                           ` Mark Kettenis
2012-05-12 15:26 ` Three weeks to branching (gdb 7.5 release) Doug Evans
2012-05-20 14:59   ` Doug Evans
2012-06-11 15:35     ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
2012-06-11 15:52       ` Doug Evans
2012-06-11 16:00         ` Joel Brobecker
2012-06-21 20:20         ` Joel Brobecker
2012-06-21 20:25           ` Doug Evans
2012-06-22 14:47           ` Jan Kratochvil
2012-06-22 16:32             ` Joel Brobecker
2012-06-22 16:41               ` Jan Kratochvil
2012-06-22 17:38                 ` Branching time + 1 week Tom Tromey
2012-06-22 20:31                 ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") Joel Brobecker
2012-06-24  9:14                   ` [commit] gnulib update [Re: Branching time + 1 week] Jan Kratochvil
2012-06-22 16:42               ` Branching time + 1 week (was: "Re: Three weeks to branching (gdb 7.5 release)") H.J. Lu
2012-06-11 15:59       ` H.J. Lu
2012-06-11 16:11         ` Joel Brobecker
2012-06-11 16:20           ` H.J. Lu
2012-05-29 17:17 ` Three weeks to branching (gdb 7.5 release) Jan Kratochvil
2012-05-30 22:04   ` Joel Brobecker
2012-06-07 19:36     ` Maciej W. Rozycki
2012-06-11 14:58       ` Joel Brobecker
2012-06-12 15:39         ` Maciej W. Rozycki

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox