[RFC] Passing MIPS debug hints between gcc and gdb

[RFC] Passing MIPS debug hints between gcc and gdb

[Fred Fish]

Since this issue affects both gcc and gdb I'm posting this to both
lists.

Currently gcc supports generating two zero content sections, the names
of which are supposed to be used by gdb.

One specifies the ABI, is of the form ".mdebug.abiXX", and gdb does
currently look for it.

Another has a name of the form ".gcc_compiled_longXX" and gdb does not
currently look for it.  This is supposed to handle the case where gcc
has been given the command line option -mlong32 or -mlong64.  Since
these can be used independently of the ABI, the current gcc code
should be changed to always generate this section.

However, the size of pointers can also be affected by -mlongXX.  In
theory we can figure out how the pointer size is affected by knowing
the ABI and other stuff, but it's much simplier to just let gcc
specify it the same way as the size of longs.

I have found, from chasing other MIPS gdb testsuite failures, that gdb
also needs to know when code has been compiled with soft float, on
hardware that supports hard float, so that it can call functions by
hand with float arguments in the right location.  So we need another
section for that.

Just to complicate things, the latest development binutils linker
removes sections with no contents, so all of these disappear in the
output file.

Below is a patch I'm successfully using in gcc.  There is a matching
patch for gdb to make use of the new sections.  There is also a patch
for newlib and binutils to prevent the sections from being deleted by
the linker.

Does anyone have any suggestions for a better way to pass these
debugging hints to gdb?

-Fred

Index: mips.c
===================================================================
RCS file: /cvsroots/latest/src/gcc/gcc/config/mips/mips.c,v
retrieving revision 1.1.1.8
diff -r1.1.1.8 mips.c
5798,5803c5798,5810
<       /* There is no ELF header flag to distinguish long32 forms of the
< 	 EABI from long64 forms.  Emit a special section to help tools
< 	 such as GDB.  */
<       if (mips_abi == ABI_EABI)
< 	fprintf (asm_out_file, "\t.section .gcc_compiled_long%d\n",
< 		 TARGET_LONG64 ? 64 : 32);
---
>       /* The -mlong32 and -mlong64 options can be used with any ABI, and may
> 	 also affect the pointer size.  There is no ELF header flag to specify
> 	 how many bits longs and pointers have. Emit special sections to help
> 	 tools such as GDB.  Also, -msoft-float can be used even when the
> 	 architecture supports hardware floats, and GDB needs to know about so
> 	 it can do the right thing when calling functions by hand. */
> 
>       fprintf (asm_out_file, "\t.section .gcc_compiled_long%d\n",
> 	       TARGET_LONG64 ? 64 : 32);
>       fprintf (asm_out_file, "\t.section .gcc_compiled_pointer%d\n",
> 	       POINTER_SIZE);
>       fprintf (asm_out_file, "\t.section .gcc_compiled_%sfloat\n",
> 	       TARGET_SOFT_FLOAT ? "soft" : "hard");

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Richard Sandiford]

Fred Fish <fnf@specifix.com> writes:
> Currently gcc supports generating two zero content sections, the names
> of which are supposed to be used by gdb.
>
> One specifies the ABI, is of the form ".mdebug.abiXX", and gdb does
> currently look for it.
>
> Another has a name of the form ".gcc_compiled_longXX" and gdb does not
> currently look for it.

Ah.  Presumably the patch to do that was never contributed then.
It does exist somewhere!

> This is supposed to handle the case where gcc has been given the
> command line option -mlong32 or -mlong64.  Since these can be used
> independently of the ABI, the current gcc code should be changed to
> always generate this section.

Right.

> However, the size of pointers can also be affected by -mlongXX.  In
> theory we can figure out how the pointer size is affected by knowing
> the ABI and other stuff, but it's much simplier to just let gcc
> specify it the same way as the size of longs.

You're right: the size of everything is determined by the combination of
the ABI "name" and long size.  The gdb patch I mentioned did do that IIRC.
(I didn't write that patch myself, and my memory's hazy.)  It was certainly
the intention that gdb work this out for itself.

> I have found, from chasing other MIPS gdb testsuite failures, that gdb
> also needs to know when code has been compiled with soft float, on
> hardware that supports hard float, so that it can call functions by
> hand with float arguments in the right location.  So we need another
> section for that.
>
> Just to complicate things, the latest development binutils linker
> removes sections with no contents, so all of these disappear in the
> output file.

Using empty sections was always a hack, to be honest (modelled on the
old .gcc_compiled_v3 thing, whatever it was called).  I suppose we
should be using note sections really.

You didn't mention it, but your patch removes the EABI conditional above
the .gcc_compiled_long* code.  I'm not comfortable with adding the
sections unconditionally though.  It may confuse IRIX.

As far as I'm concerned, EABI is the only ABI where we support both
-mlong32 and -mlong64.  ISTR someone deciding to use -mabi=o64 -mlong64
as well.  Since both EABI and o64 are basically GNU inventions, I'd be
OK with relaxing the condition to EABI || o64 if it's o64 you need this
for.  I suppose we should make the incorrect -mlong* option an error for
other ABIs.  (Another one for the TODO list.)

Richard

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Fred Fish]

On Thursday 11 May 2006 02:57, Richard Sandiford wrote:
> You're right: the size of everything is determined by the combination of
> the ABI "name" and long size.  The gdb patch I mentioned did do that IIRC.
> (I didn't write that patch myself, and my memory's hazy.)  It was certainly
> the intention that gdb work this out for itself.

OK.  I can generate a patch that does that.

> Using empty sections was always a hack, to be honest (modelled on the
> old .gcc_compiled_v3 thing, whatever it was called).  I suppose we
> should be using note sections really.

Yeah, I thought about putting the hints in a single section that could
have it's contents merged by the linker and duplicates removed.

> I'd be OK with relaxing the condition to EABI || o64 if it's o64 you
> need this for.

Yes, it is o64 where I originally found the problem.

> I suppose we should make the incorrect -mlong* option an error for
> other ABIs.  (Another one for the TODO list.)

OK, though it seemed to work fine with at least one other ABI (-mabi=32).
I didn't test them all.

-Fred

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Fred Fish]

On Thursday 11 May 2006 02:57, Richard Sandiford wrote:
> Using empty sections was always a hack, to be honest (modelled on the
> old .gcc_compiled_v3 thing, whatever it was called).  I suppose we
> should be using note sections really.

Wouldn't that be ELF specific, as well as requiring the linker to
merge hint strings?  I'm a little unclear on just what capabilities
the current linker has to merge section contents so that "hint
strings" put into a note section wouldn't be duplicated in the final
linked output, one for each compilation unit.

How about just creating common symbols, which will be merged.  That
takes up less space than a section in the executable file, but does
contribute something to the size of of the loaded uninitialized
segment.  I.E. if I add the following to mips_file_start():

      {
        char buf[32];
        sprintf (buf, "__%s", abi_string);
        mips_declare_common_object (asm_out_file, buf, "\n\t.comm\t", 4, 0, true);
      }

cc1 then generates:

        .comm   __abiO64,4,0

in each output.  The linker should then merge all these into a single
symbol in the output, which gdb could easily search for.

-Fred 

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Mark Mitchell]

Fred Fish wrote:
> On Thursday 11 May 2006 02:57, Richard Sandiford wrote:
>> Using empty sections was always a hack, to be honest (modelled on the
>> old .gcc_compiled_v3 thing, whatever it was called).  I suppose we
>> should be using note sections really.
> 
> Wouldn't that be ELF specific, as well as requiring the linker to
> merge hint strings?  I'm a little unclear on just what capabilities
> the current linker has to merge section contents so that "hint
> strings" put into a note section wouldn't be duplicated in the final
> linked output, one for each compilation unit.

The ARM EABI contains a specification for object-file attributes,
including rules about how to merge them.  The specification is quite
general; there are mechanisms for compiler extension, etc.

It is indeed ELF-specific, but I would guess you could use the same
technique on other object formats that allow additional sections.

I'm not sure what the current state of support for this feature is in
Binutils, but I think we should consider using the ARM strategy on all
platforms without a previously defined mechanism of their own; we want
it anyhow (for ARM), and we can presumably avoid duplicate effort/code
by reusing the code.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Richard Sandiford]

Mark Mitchell <mark@codesourcery.com> writes:
> Fred Fish wrote:
>> On Thursday 11 May 2006 02:57, Richard Sandiford wrote:
>>> Using empty sections was always a hack, to be honest (modelled on the
>>> old .gcc_compiled_v3 thing, whatever it was called).  I suppose we
>>> should be using note sections really.
>> 
>> Wouldn't that be ELF specific, [...]

Yes, but that isn't a problem.  MIPS gcc only supports ELF targets
these days.

>> [...] as well as requiring the linker to
>> merge hint strings?  I'm a little unclear on just what capabilities
>> the current linker has to merge section contents so that "hint
>> strings" put into a note section wouldn't be duplicated in the final
>> linked output, one for each compilation unit.
>
> The ARM EABI contains a specification for object-file attributes,
> including rules about how to merge them.  The specification is quite
> general; there are mechanisms for compiler extension, etc.
>
> It is indeed ELF-specific, but I would guess you could use the same
> technique on other object formats that allow additional sections.
>
> I'm not sure what the current state of support for this feature is in
> Binutils, but I think we should consider using the ARM strategy on all
> platforms without a previously defined mechanism of their own; we want
> it anyhow (for ARM), and we can presumably avoid duplicate effort/code
> by reusing the code.

I haven't looked at the ARM EABI in detail, but FWIW, that principle
sounds good to me too.  I agree that it's better to avoid reinventing
the wheel.

Richard

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Fred Fish]

On Thursday 11 May 2006 02:57, Richard Sandiford wrote:

> Since both EABI and o64 are basically GNU inventions, I'd be OK with
> relaxing the condition to EABI || o64 if it's o64 you need this for.

OK, here is a gcc patch to do that, and a matching gdb patch to use 
it.

If the gcc patch is approved, please check it in as I don't currently
have gcc write access.

-Fred


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

2006-06-12  Fred Fish  <fnf@specifix.com>

	* config/mips/mips.c (mips_file_start): Create special section
	".gcc_compiled_longXX" for o64 ABI as well as EABI.

Index: config/mips/mips.c
===================================================================
RCS file: /cvsroots/latest/src/gcc/gcc/config/mips/mips.c,v
retrieving revision 1.1.1.9
diff -u -p -r1.1.1.9 mips.c
--- config/mips/mips.c	11 May 2006 18:41:03 -0000	1.1.1.9
+++ config/mips/mips.c	11 Jun 2006 18:01:07 -0000
@@ -5831,7 +5831,8 @@ mips_file_start (void)
       /* There is no ELF header flag to distinguish long32 forms of the
 	 EABI from long64 forms.  Emit a special section to help tools
 	 such as GDB.  */
-      if (mips_abi == ABI_EABI)
+      if (mips_abi == ABI_EABI
+	  || mips_abi == ABI_O64)
 	fprintf (asm_out_file, "\t.section .gcc_compiled_long%d\n",
 		 TARGET_LONG64 ? 64 : 32);
 


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


2006-06-12  Fred Fish  <fnf@specifix.com>

	* mips-tdep.c (mips_find_long_section): New function.
	(mips_gdbarch_init): Use it to set long and pointer sizes.

Index: mips-tdep.c
===================================================================
RCS file: /cvsroots/latest/src/gdb/gdb/mips-tdep.c,v
retrieving revision 1.1.1.8
diff -c -p -r1.1.1.8 mips-tdep.c
*** mips-tdep.c	10 Jun 2006 03:32:42 -0000	1.1.1.8
--- mips-tdep.c	11 Jun 2006 18:11:09 -0000
*************** mips_find_abi_section (bfd *abfd, asecti
*** 4690,4695 ****
--- 4690,4709 ----
      warning (_("unsupported ABI %s."), name + 8);
  }
  
+ static void
+ mips_find_long_section (bfd *abfd, asection *sect, void *obj)
+ {
+   int *lbp = (int *) obj;
+   const char *name = bfd_get_section_name (abfd, sect);
+ 
+   if (strncmp (name, ".gcc_compiled_long32", 20) == 0)
+     *lbp = 32;
+   else if (strncmp (name, ".gcc_compiled_long64", 20) == 0)
+     *lbp = 64;
+   else if (strncmp (name, ".gcc_compiled_long", 18) == 0)
+     warning (_("unrecognized .gcc_compiled_longXX"));
+ }
+ 
  static enum mips_abi
  global_mips_abi (void)
  {
*************** mips_gdbarch_init (struct gdbarch_info i
*** 5009,5014 ****
--- 5023,5080 ----
        internal_error (__FILE__, __LINE__, _("unknown ABI in switch"));
      }
  
+   /* GCC creates a pseudo-section whose name specifies the size of
+      longs, since -mlong32 or -mlong64 may be used independent of
+      other options.  How those options affect pointer sizes is ABI and
+      architecture dependent, so use them to override the default sizes
+      set by the ABI.  This table shows the relationship between ABI,
+      -mlongXX, and size of pointers:
+ 
+      ABI		-mlongXX	ptr bits
+      ---		--------	--------
+      o32		32		32
+      o32		64		32
+      n32		32		32
+      n32		64		64
+      o64		32		32
+      o64		64		64
+      n64		32		32
+      n64		64		64
+      eabi32		32		32
+      eabi32		64		32
+      eabi64		32		32
+      eabi64		64		64
+ 
+     Note that for o32 and eabi32, pointers are always 32 bits
+     regardless of any -mlongXX option.  For all others, pointers and
+     longs are the same, as set by -mlongXX or set by defaults.
+  */
+ 
+   if (info.abfd != NULL)
+     {
+       int long_bit = 0;
+ 
+       bfd_map_over_sections (info.abfd, mips_find_long_section, &long_bit);
+       if (long_bit)
+ 	{
+ 	  set_gdbarch_long_bit (gdbarch, long_bit);
+ 	  switch (mips_abi)
+ 	    {
+ 	    case MIPS_ABI_O32:
+ 	    case MIPS_ABI_EABI32:
+ 	      break;
+ 	    case MIPS_ABI_N32:
+ 	    case MIPS_ABI_O64:
+ 	    case MIPS_ABI_N64:
+ 	    case MIPS_ABI_EABI64:
+ 	      set_gdbarch_ptr_bit (gdbarch, long_bit);
+ 	      break;
+ 	    default:
+ 	      internal_error (__FILE__, __LINE__, _("unknown ABI in switch"));
+ 	    }
+ 	}
+     }
+ 
    /* FIXME: jlarmour/2000-04-07: There *is* a flag EF_MIPS_32BIT_MODE
       that could indicate -gp32 BUT gas/config/tc-mips.c contains the
       comment:

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Richard Sandiford]

Fred Fish <fnf@specifix.com> writes:
> 2006-06-12  Fred Fish  <fnf@specifix.com>
>
> 	* config/mips/mips.c (mips_file_start): Create special section
> 	".gcc_compiled_longXX" for o64 ABI as well as EABI.

Applied.  I tweaked the comment to mention o64 as well, so for the
record, here's what went in.

Richard

Index: config/mips/mips.c
===================================================================
--- config/mips/mips.c	(revision 114565)
+++ config/mips/mips.c	(working copy)
@@ -5830,8 +5830,9 @@ mips_file_start (void)
 
       /* There is no ELF header flag to distinguish long32 forms of the
 	 EABI from long64 forms.  Emit a special section to help tools
-	 such as GDB.  */
-      if (mips_abi == ABI_EABI)
+	 such as GDB.  Do the same for o64, which is sometimes used with
+	 -mlong64.  */
+      if (mips_abi == ABI_EABI || mips_abi == ABI_O64)
 	fprintf (asm_out_file, "\t.section .gcc_compiled_long%d\n",
 		 TARGET_LONG64 ? 64 : 32);
 

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Fred Fish]

On Monday 12 June 2006 06:11, Fred Fish wrote:
> OK, here is a gcc patch to do that, and a matching gdb patch to use 
> it.

Anyone want to review the gdb patch?  :-)

Thanks.

-Fred

Re: [RFC] Passing MIPS debug hints between gcc and gdb

[Daniel Jacobowitz]

On Tue, Jun 13, 2006 at 12:10:28PM -0400, Fred Fish wrote:
> On Monday 12 June 2006 06:11, Fred Fish wrote:
> > OK, here is a gcc patch to do that, and a matching gdb patch to use 
> > it.
> 
> Anyone want to review the gdb patch?  :-)

It's OK to commit.

-- 
Daniel Jacobowitz
CodeSourcery