[RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Pierre Muller]

  On 64-bit targets, stabs suffers from the fact that addresses
are only stored as 32-bit values.

  For mingw64, I was able to debug executables loaded
at address 0x100000000 (the default location for executables
compiled by Free Pascal Compiler) by using the simple
patch below.

  The idea of the patch is quite basic:
  add the 32 high bits of text_addr as
to the offsets of all sections in read_dbx_symtab.

  I don't know if this is mingw64 (possibly 64-bit PE) specific or not...

All those offsets seemed to be at zero at the time I added
the high 32-bit part of text_addr, but maybe other
targets do something else... If this should not be applied
for other 64-bit targets, we could of course modify
the tests before changing the offsets, restricting it to
targets for which it is relevant.

  I just tried to use gcc to compile an executable
with -Wl,--image-base,0x300000000, to force high load address,
but this lead to lots of messages:
relocation truncated to fit R_X86_64_32 against .text
Free Pascal compiler doesn't seem to generate any of those
time of relocations... 

  Comments welcome,


Pierre Muller
Pascal language support maintainer for GDB


  

2010-09-14  Pierre Muller  <muller@ics.u-strasbg.fr>

	* dbxread.c (read_dbx_symtab): Add high part of text_addr value
	to all section offsets.

Index: src/gdb/dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.116
diff -u -p -r1.116 dbxread.c
--- src/gdb/dbxread.c	14 May 2010 17:53:15 -0000	1.116
+++ src/gdb/dbxread.c	1 Sep 2010 08:01:01 -0000
@@ -1216,6 +1216,22 @@ read_dbx_symtab (struct objfile *objfile
   text_addr = DBX_TEXT_ADDR (objfile);
   text_size = DBX_TEXT_SIZE (objfile);
 
+#ifdef BFD64
+  {
+    /* stabs internal format only has 4 bytes for address.
+       Use high dword of text address to fix global addresses.
+       FIXME: this only works if the whole executable has the same
+       high part address.  */
+    CORE_ADDR stabs_fixup = text_addr & ~((CORE_ADDR) 0xffffffff);
+    if (stabs_fixup)
+      {
+        objfile->section_offsets->offsets[SECT_OFF_TEXT (objfile)] += stabs_fixup;
+	objfile->section_offsets->offsets[SECT_OFF_DATA (objfile)] += stabs_fixup;
+	objfile->section_offsets->offsets[SECT_OFF_BSS (objfile)] += stabs_fixup;
+      }
+  }
+#endif /* BFD64 */
+
   /* FIXME.  We probably want to change stringtab_global rather than add this
      while processing every symbol entry.  FIXME.  */
   file_string_table_offset = 0;

Re: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Tristan Gingold]

On Sep 14, 2010, at 5:04 PM, Pierre Muller wrote:

>  On 64-bit targets, stabs suffers from the fact that addresses
> are only stored as 32-bit values.
> 
>  For mingw64, I was able to debug executables loaded
> at address 0x100000000 (the default location for executables
> compiled by Free Pascal Compiler) by using the simple
> patch below.
> 
>  The idea of the patch is quite basic:
>  add the 32 high bits of text_addr as
> to the offsets of all sections in read_dbx_symtab.
> 
>  I don't know if this is mingw64 (possibly 64-bit PE) specific or not...
> 
> All those offsets seemed to be at zero at the time I added
> the high 32-bit part of text_addr, but maybe other
> targets do something else... If this should not be applied
> for other 64-bit targets, we could of course modify
> the tests before changing the offsets, restricting it to
> targets for which it is relevant.
> 
>  I just tried to use gcc to compile an executable
> with -Wl,--image-base,0x300000000, to force high load address,
> but this lead to lots of messages:
> relocation truncated to fit R_X86_64_32 against .text
> Free Pascal compiler doesn't seem to generate any of those
> time of relocations... 
> 
>  Comments welcome,

I think that some 64 bits targets have 8 bytes for the address.

Tristan.

RE: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Pierre Muller]

> >  Comments welcome,
> 
> I think that some 64 bits targets have 8 bytes for the address.

  
  Of course, dwarf debugging doesn't suffer from this limitation,
and uses 8-byte for addresses.
  This is the default format for most 64-bit targets,
and it is the preferred debugging format for 64-bit
because of this 4-byte limitation of stabs...
  So this is really a marginal case that I presented here.


  The thing is that, for Free Pascal, we have lots of
troubles with DWARF (and some 64-bit specific), 
thus I would like to be able to use STABS format (which 
is less troublesome) but that also didn't work
because of this high address default base used by this compiler.

Pierre
  

Re: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Michael Snyder]

Pierre Muller wrote:
>   On 64-bit targets, stabs suffers from the fact that addresses
> are only stored as 32-bit values.
> 
>   For mingw64, I was able to debug executables loaded
> at address 0x100000000 (the default location for executables
> compiled by Free Pascal Compiler) by using the simple
> patch below.
> 
>   The idea of the patch is quite basic:
>   add the 32 high bits of text_addr as
> to the offsets of all sections in read_dbx_symtab.
> 
>   I don't know if this is mingw64 (possibly 64-bit PE) specific or not...
> 
> All those offsets seemed to be at zero at the time I added
> the high 32-bit part of text_addr, but maybe other
> targets do something else... If this should not be applied
> for other 64-bit targets, we could of course modify
> the tests before changing the offsets, restricting it to
> targets for which it is relevant.
> 
>   I just tried to use gcc to compile an executable
> with -Wl,--image-base,0x300000000, to force high load address,
> but this lead to lots of messages:
> relocation truncated to fit R_X86_64_32 against .text
> Free Pascal compiler doesn't seem to generate any of those
> time of relocations... 
> 
>   Comments welcome,

I don't see any intrinsic harm in it, since it will only affect stabs
binaries when BFD64 is defined.

This is just a comment, though, not an approval.

> 2010-09-14  Pierre Muller  <muller@ics.u-strasbg.fr>
> 
> 	* dbxread.c (read_dbx_symtab): Add high part of text_addr value
> 	to all section offsets.
> 
> Index: src/gdb/dbxread.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/dbxread.c,v
> retrieving revision 1.116
> diff -u -p -r1.116 dbxread.c
> --- src/gdb/dbxread.c	14 May 2010 17:53:15 -0000	1.116
> +++ src/gdb/dbxread.c	1 Sep 2010 08:01:01 -0000
> @@ -1216,6 +1216,22 @@ read_dbx_symtab (struct objfile *objfile
>    text_addr = DBX_TEXT_ADDR (objfile);
>    text_size = DBX_TEXT_SIZE (objfile);
>  
> +#ifdef BFD64
> +  {
> +    /* stabs internal format only has 4 bytes for address.
> +       Use high dword of text address to fix global addresses.
> +       FIXME: this only works if the whole executable has the same
> +       high part address.  */
> +    CORE_ADDR stabs_fixup = text_addr & ~((CORE_ADDR) 0xffffffff);
> +    if (stabs_fixup)
> +      {
> +        objfile->section_offsets->offsets[SECT_OFF_TEXT (objfile)] += stabs_fixup;
> +	objfile->section_offsets->offsets[SECT_OFF_DATA (objfile)] += stabs_fixup;
> +	objfile->section_offsets->offsets[SECT_OFF_BSS (objfile)] += stabs_fixup;
> +      }
> +  }
> +#endif /* BFD64 */
> +
>    /* FIXME.  We probably want to change stringtab_global rather than add this
>       while processing every symbol entry.  FIXME.  */
>    file_string_table_offset = 0;
> 

Re: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Joel Brobecker]

> I don't see any intrinsic harm in it, since it will only affect stabs
> binaries when BFD64 is defined.

I don't know what the effect might be on the 64bit platforms out there
that still use stabs (Eg. alpha-tru64).

-- 
Joel

Re: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Tom Tromey]

>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> writes:

Pierre>   The thing is that, for Free Pascal, we have lots of
Pierre> troubles with DWARF (and some 64-bit specific), 

Can we also fix that somehow?

Tom

Re: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Tristan Gingold]

On Sep 14, 2010, at 5:24 PM, Pierre Muller wrote:

>>> Comments welcome,
>> 
>> I think that some 64 bits targets have 8 bytes for the address.
> 
> 
>  Of course, dwarf debugging doesn't suffer from this limitation,
> and uses 8-byte for addresses.
>  This is the default format for most 64-bit targets,
> and it is the preferred debugging format for 64-bit
> because of this 4-byte limitation of stabs...
>  So this is really a marginal case that I presented here.

To clarify, I meant that some 64 bits targets have 8 bytes for the address in *stabs*.
(eg: darwin64 - but the use of stabs is deprecated for this target).

OTOH, dbxread.c seems to be bound to 32-bits stabs address.

I am not sure it is right to set objfile->section_offsets->offsets.

>  The thing is that, for Free Pascal, we have lots of
> troubles with DWARF (and some 64-bit specific), 
> thus I would like to be able to use STABS format (which 
> is less troublesome) but that also didn't work
> because of this high address default base used by this compiler.

So, it might be worth fixing Free Pascal too !

Tristan.

RE: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tristan Gingold
> Envoyé : Wednesday, September 15, 2010 9:29 AM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFC] Improve stabs debugging for mingw64 executables
> loaded at high addresses
> 
> 
> On Sep 14, 2010, at 5:24 PM, Pierre Muller wrote:
> 
> >>> Comments welcome,
> >>
> >> I think that some 64 bits targets have 8 bytes for the address.
> >
> >
> >  Of course, dwarf debugging doesn't suffer from this limitation,
> > and uses 8-byte for addresses.
> >  This is the default format for most 64-bit targets,
> > and it is the preferred debugging format for 64-bit
> > because of this 4-byte limitation of stabs...
> >  So this is really a marginal case that I presented here.
> 
> To clarify, I meant that some 64 bits targets have 8 bytes for the
> address in *stabs*.
> (eg: darwin64 - but the use of stabs is deprecated for this target).

  Sorry for misunderstanding you.
  I didn't know about a 64-bit version of stabs.
  This is not in GNU binutils then, because
bfd/stabs.c still has a macro called STABSIZE equal to 12
which only allows for a 4-byte address at offset 8 for stab value field.
  There is a FIXME at line 39:
"FIXME: This will have to change for a 64-bit object format."

But nothing changed in code apparently.
  Where is the source of the support for 64-bit stabs for darwin64?

 
> OTOH, dbxread.c seems to be bound to 32-bits stabs address.

  Which seems logical as also bfd only supports 32-bit,
I would be interested in extending support for 64-bit
stabs (which I would then implement inside Free Pascal too).
 
> I am not sure it is right to set objfile->section_offsets->offsets.

  I am not either, that why this is really only a
Request For Comments!
  
> >  The thing is that, for Free Pascal, we have lots of
> > troubles with DWARF (and some 64-bit specific),
> > thus I would like to be able to use STABS format (which
> > is less troublesome) but that also didn't work
> > because of this high address default base used by this compiler.
> 
> So, it might be worth fixing Free Pascal too !
  I could change the default load address inside Free Pascal Source
if stabs is used, but I wanted to try this out,
and as it seemed to help, I wanted to share it as a RFC.
  
  But this addition would allow to handle dynamic libraries
(whose load address might be above the 0x100000000 threshold).
But I remember that for windows at least, there is an
incompatibility between relocation and stabs.

Pierre

RE: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : Tuesday, September 14, 2010 7:32 PM
> À : Michael Snyder
> Cc : Pierre Muller; gdb-patches@sourceware.org
> Objet : Re: [RFC] Improve stabs debugging for mingw64 executables
> loaded at high addresses
> 
> > I don't see any intrinsic harm in it, since it will only affect stabs
> > binaries when BFD64 is defined.
> 
> I don't know what the effect might be on the 64bit platforms out there
> that still use stabs (Eg. alpha-tru64).

  Sorry, but I have no access to such a machine :(
Will be difficult to test...

Pierre

RE: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Tom Tromey
> Envoyé : Tuesday, September 14, 2010 8:15 PM
> À : Pierre Muller
> Cc : 'Tristan Gingold'; gdb-patches@sourceware.org
> Objet : Re: [RFC] Improve stabs debugging for mingw64 executables
> loaded at high addresses
> 
> >>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
> writes:
> 
> Pierre>   The thing is that, for Free Pascal, we have lots of
> Pierre> troubles with DWARF (and some 64-bit specific),
> 
> Can we also fix that somehow?

  I hope to work on it, but starting with
usable stabs debug info to debug dwarf debug info problems
would make life much more easy.

Pierre

Re: [RFC] Improve stabs debugging for mingw64 executables loaded at high addresses

[Tristan Gingold]

On Sep 15, 2010, at 10:24 AM, Pierre Muller wrote:

>  This is not in GNU binutils then, because
> bfd/stabs.c still has a macro called STABSIZE equal to 12
> which only allows for a 4-byte address at offset 8 for stab value field.
>  There is a FIXME at line 39:
> "FIXME: This will have to change for a 64-bit object format."

bfd/stabs.c is only for linking.

> But nothing changed in code apparently.
>  Where is the source of the support for 64-bit stabs for darwin64?

bfd/mach-o.c:bfd_mach_o_read_symtab_symbol
and
gdb/machoread.c:macho_symtab_read (this doesn't use dbxread.c)

>> OTOH, dbxread.c seems to be bound to 32-bits stabs address.
> 
>  Which seems logical as also bfd only supports 32-bit,
> I would be interested in extending support for 64-bit
> stabs (which I would then implement inside Free Pascal too).
> 
>> I am not sure it is right to set objfile->section_offsets->offsets.
> 
>  I am not either, that why this is really only a
> Request For Comments!
> 
>>> The thing is that, for Free Pascal, we have lots of
>>> troubles with DWARF (and some 64-bit specific),
>>> thus I would like to be able to use STABS format (which
>>> is less troublesome) but that also didn't work
>>> because of this high address default base used by this compiler.
>> 
>> So, it might be worth fixing Free Pascal too !
>  I could change the default load address inside Free Pascal Source
> if stabs is used, but I wanted to try this out,
> and as it seemed to help, I wanted to share it as a RFC.
> 
>  But this addition would allow to handle dynamic libraries
> (whose load address might be above the 0x100000000 threshold).
> But I remember that for windows at least, there is an
> incompatibility between relocation and stabs.
> 
> Pierre
> 
>