[rfc] For mips, sign-extended ecoff offsets

[rfc] For mips, sign-extended ecoff offsets

[Andrew Cagney]

Hello,

The attatched patch changes the MIPS ELF32 backend so that it is more
likely to return a sign-extended offset.  At present the ELF backend
returns sign-extended symbol table values but not sign extended debug
information.

For instance, an asymbol might contain 0xfffffffa0100124 yet the value
returned by ecoff_swap_sym_in() is 0xa0100124.

Preliminary tests with GDB suggest this improves things significantly. 
Next question is, what damage is this likely to do to BFD and the
linker.

	Andrew

PS: This will hurt GDB more than it can hurt BFD :-)
Mon Jun 19 20:53:14 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* ecoffswap.h (ecoff_get_off, ecoff_put_off): Add ECOFF_SIGNED_32
 	and ECOF_SIGNED_64 to list ways to extract an offset.
	* elf64-mips.c (ECOFF_SIGNED_64): Define instead of ECOFF_64.
	* elf32-mips.c (ECOFF_SIGNED_32): Define instead of ECOFF_32.

Index: ecoffswap.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/ecoffswap.h,v
retrieving revision 1.19
diff -p -r1.19 ecoffswap.h
*** ecoffswap.h	1996/03/12 22:41:13	1.19
--- ecoffswap.h	2000/06/19 11:56:25
*************** Foundation, Inc., 59 Temple Place - Suit
*** 27,36 ****
     on them in gdb by naming the including source file; e.g.,
     'coff-mips.c':ecoff_swap_hdr_in.
  
!    Before including this header file, one of ECOFF_32 or ECOFF_64 must
!    be defined.  These are checked when swapping information that
!    depends upon the target size.  This code works for 32 bit and 64
!    bit ECOFF, but may need to be generalized in the future.
  
     Some header file which defines the external forms of these
     structures must also be included before including this header file.
--- 27,37 ----
     on them in gdb by naming the including source file; e.g.,
     'coff-mips.c':ecoff_swap_hdr_in.
  
!    Before including this header file, one of ECOFF_32, ECOFF_64,
!    ECOF_SIGNED_32 or ECOFF_SIGNED_64 must be defined.  These are
!    checked when swapping information that depends upon the target
!    size.  This code works for 32 bit and 64 bit ECOFF, but may need to
!    be generalized in the future.
  
     Some header file which defines the external forms of these
     structures must also be included before including this header file.
*************** Foundation, Inc., 59 Temple Place - Suit
*** 49,54 ****
--- 50,63 ----
  #ifdef ECOFF_64
  #define ecoff_get_off bfd_h_get_64
  #define ecoff_put_off bfd_h_put_64
+ #endif
+ #ifdef ECOFF_SIGNED_32
+ #define ecoff_get_off bfd_h_get_signed_32
+ #define ecoff_put_off bfd_h_put_signed_32
+ #endif
+ #ifdef ECOFF_SIGNED_64
+ #define ecoff_get_off bfd_h_get_signed_32
+ #define ecoff_put_off bfd_h_put_signed_32
  #endif
  
  /* ECOFF auxiliary information swapping routines.  These are the same
Index: elf32-mips.c
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf32-mips.c,v
retrieving revision 1.176
diff -p -r1.176 elf32-mips.c
*** elf32-mips.c	2000/05/29 16:45:57	1.176
--- elf32-mips.c	2000/06/19 11:56:44
*************** Foundation, Inc., 59 Temple Place - Suit
*** 40,46 ****
  #include "coff/internal.h"
  #include "coff/ecoff.h"
  #include "coff/mips.h"
! #define ECOFF_32
  #include "ecoffswap.h"
  
  /* This structure is used to hold .got information when linking.  It
--- 40,46 ----
  #include "coff/internal.h"
  #include "coff/ecoff.h"
  #include "coff/mips.h"
! #define ECOFF_SIGNED_32
  #include "ecoffswap.h"
  
  /* This structure is used to hold .got information when linking.  It
Index: elf64-mips.c
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf64-mips.c,v
retrieving revision 1.18
diff -p -r1.18 elf64-mips.c
*** elf64-mips.c	1999/12/10 10:49:53	1.18
--- elf64-mips.c	2000/06/19 11:56:46
*************** Foundation, Inc., 59 Temple Place - Suit
*** 45,51 ****
  #include "coff/ecoff.h"
  /* The 64 bit versions of the mdebug data structures are in alpha.h.  */
  #include "coff/alpha.h"
! #define ECOFF_64
  #include "ecoffswap.h"
  
  static void mips_elf64_swap_reloc_in
--- 45,51 ----
  #include "coff/ecoff.h"
  /* The 64 bit versions of the mdebug data structures are in alpha.h.  */
  #include "coff/alpha.h"
! #define ECOFF_SIGNED_64
  #include "ecoffswap.h"
  
  static void mips_elf64_swap_reloc_in

Re: [rfc] For mips, sign-extended ecoff offsets

[Alan Modra]

On Mon, 19 Jun 2000, Andrew Cagney wrote:

> The attatched patch changes the MIPS ELF32 backend so that it is more
> likely to return a sign-extended offset.  At present the ELF backend
> returns sign-extended symbol table values but not sign extended debug
> information.

Hi Andrew,
   Would it be better to just change ecoff_swap_sym_in?  It seems like
this would achieve what you want, and not risk breaking quite so much.
I'm worried about what happens if things like PDR.adr get changed from
0xa0000000 to 0xffffffffa0000000.

Regards, Alan Modra.
-- 
Linuxcare.  Support for the Revolution.

Re: [rfc] For mips, sign-extended ecoff offsets

[Andrew Cagney]

Alan Modra wrote:
> 
> On Mon, 19 Jun 2000, Andrew Cagney wrote:
> 
> > The attatched patch changes the MIPS ELF32 backend so that it is more
> > likely to return a sign-extended offset.  At present the ELF backend
> > returns sign-extended symbol table values but not sign extended debug
> > information.
> 
> Hi Andrew,
>    Would it be better to just change ecoff_swap_sym_in?  It seems like
> this would achieve what you want, and not risk breaking quite so much.
> I'm worried about what happens if things like PDR.adr get changed from
> 0xa0000000 to 0xffffffffa0000000.

Thats why I'm asking :-) Remember though, on the MIPS platform, if
``PDR.adr'' is an address then, the canonical form of the value
``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. 
GDB and BFD have, for too many years, been bribed and cajoled into
perpetuated the lie that MIPS doesn't sign extend addresses.   GDB's now
decided to come clean on this matter (and purge an amazing amount of
bogus code :-).

Any way I've attached a revised patch.  I wasn't ruthless enough the
first time....  With this revision the linker appears to work :-) 
Testing is continuing.

I guess the question for BFD people is, is this the correct approach to
fixing this bug?

	Andrew
Mon Jun 19 20:53:14 2000  Andrew Cagney  <cagney@b1.cygnus.com>

	* ecoffswap.h (ecoff_get_off, ecoff_put_off): Add ECOFF_SIGNED_32
 	and ECOF_SIGNED_64 to list ways to extract an offset.
	* elf64-mips.c (ECOFF_SIGNED_64): Define instead of ECOFF_64.
	* elf32-mips.c (ECOFF_SIGNED_32): Define instead of ECOFF_32.

Index: ecoffswap.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/ecoffswap.h,v
retrieving revision 1.19
diff -p -r1.19 ecoffswap.h
*** ecoffswap.h	1996/03/12 22:41:13	1.19
--- ecoffswap.h	2000/06/20 01:02:48
*************** Foundation, Inc., 59 Temple Place - Suit
*** 27,36 ****
     on them in gdb by naming the including source file; e.g.,
     'coff-mips.c':ecoff_swap_hdr_in.
  
!    Before including this header file, one of ECOFF_32 or ECOFF_64 must
!    be defined.  These are checked when swapping information that
!    depends upon the target size.  This code works for 32 bit and 64
!    bit ECOFF, but may need to be generalized in the future.
  
     Some header file which defines the external forms of these
     structures must also be included before including this header file.
--- 27,37 ----
     on them in gdb by naming the including source file; e.g.,
     'coff-mips.c':ecoff_swap_hdr_in.
  
!    Before including this header file, one of ECOFF_32, ECOFF_64,
!    ECOF_SIGNED_32 or ECOFF_SIGNED_64 must be defined.  These are
!    checked when swapping information that depends upon the target
!    size.  This code works for 32 bit and 64 bit ECOFF, but may need to
!    be generalized in the future.
  
     Some header file which defines the external forms of these
     structures must also be included before including this header file.
*************** Foundation, Inc., 59 Temple Place - Suit
*** 50,55 ****
--- 51,64 ----
  #define ecoff_get_off bfd_h_get_64
  #define ecoff_put_off bfd_h_put_64
  #endif
+ #ifdef ECOFF_SIGNED_32
+ #define ecoff_get_off bfd_h_get_signed_32
+ #define ecoff_put_off bfd_h_put_signed_32
+ #endif
+ #ifdef ECOFF_SIGNED_64
+ #define ecoff_get_off bfd_h_get_signed_64
+ #define ecoff_put_off bfd_h_put_signed_64
+ #endif
  
  /* ECOFF auxiliary information swapping routines.  These are the same
     for all ECOFF targets, so they are defined in ecofflink.c.  */
*************** ecoff_swap_fdr_in (abfd, ext_copy, inter
*** 185,191 ****
    
    intern->adr           = ecoff_get_off (abfd, (bfd_byte *)ext->f_adr);
    intern->rss           = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_rss);
! #ifdef ECOFF_64
    if (intern->rss == 0xffffffff)
      intern->rss = -1;
  #endif
--- 194,200 ----
    
    intern->adr           = ecoff_get_off (abfd, (bfd_byte *)ext->f_adr);
    intern->rss           = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_rss);
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
    if (intern->rss == 0xffffffff)
      intern->rss = -1;
  #endif
*************** ecoff_swap_fdr_in (abfd, ext_copy, inter
*** 197,207 ****
    intern->cline         = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_cline);
    intern->ioptBase      = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_ioptBase);
    intern->copt          = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_copt);
! #ifdef ECOFF_32
    intern->ipdFirst      = bfd_h_get_16 (abfd, (bfd_byte *)ext->f_ipdFirst);
    intern->cpd           = bfd_h_get_16 (abfd, (bfd_byte *)ext->f_cpd);
  #endif
! #ifdef ECOFF_64
    intern->ipdFirst      = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_ipdFirst);
    intern->cpd           = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_cpd);
  #endif
--- 206,216 ----
    intern->cline         = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_cline);
    intern->ioptBase      = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_ioptBase);
    intern->copt          = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_copt);
! #if defined (ECOFF_32) || defined (ECOFF_SIGNED_32)
    intern->ipdFirst      = bfd_h_get_16 (abfd, (bfd_byte *)ext->f_ipdFirst);
    intern->cpd           = bfd_h_get_16 (abfd, (bfd_byte *)ext->f_cpd);
  #endif
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
    intern->ipdFirst      = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_ipdFirst);
    intern->cpd           = bfd_h_get_32 (abfd, (bfd_byte *)ext->f_cpd);
  #endif
*************** ecoff_swap_fdr_out (abfd, intern_copy, e
*** 262,272 ****
    bfd_h_put_32 (abfd, intern->cline, (bfd_byte *)ext->f_cline);
    bfd_h_put_32 (abfd, intern->ioptBase, (bfd_byte *)ext->f_ioptBase);
    bfd_h_put_32 (abfd, intern->copt, (bfd_byte *)ext->f_copt);
! #ifdef ECOFF_32
    bfd_h_put_16 (abfd, intern->ipdFirst, (bfd_byte *)ext->f_ipdFirst);
    bfd_h_put_16 (abfd, intern->cpd, (bfd_byte *)ext->f_cpd);
  #endif
! #ifdef ECOFF_64
    bfd_h_put_32 (abfd, intern->ipdFirst, (bfd_byte *)ext->f_ipdFirst);
    bfd_h_put_32 (abfd, intern->cpd, (bfd_byte *)ext->f_cpd);
  #endif
--- 271,281 ----
    bfd_h_put_32 (abfd, intern->cline, (bfd_byte *)ext->f_cline);
    bfd_h_put_32 (abfd, intern->ioptBase, (bfd_byte *)ext->f_ioptBase);
    bfd_h_put_32 (abfd, intern->copt, (bfd_byte *)ext->f_copt);
! #if defined (ECOFF_32) || defined (ECOFF_SIGNED_32)
    bfd_h_put_16 (abfd, intern->ipdFirst, (bfd_byte *)ext->f_ipdFirst);
    bfd_h_put_16 (abfd, intern->cpd, (bfd_byte *)ext->f_cpd);
  #endif
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
    bfd_h_put_32 (abfd, intern->ipdFirst, (bfd_byte *)ext->f_ipdFirst);
    bfd_h_put_32 (abfd, intern->cpd, (bfd_byte *)ext->f_cpd);
  #endif
*************** ecoff_swap_pdr_in (abfd, ext_copy, inter
*** 341,347 ****
    intern->lnHigh        = bfd_h_get_32 (abfd, (bfd_byte *)ext->p_lnHigh);
    intern->cbLineOffset  = ecoff_get_off (abfd, (bfd_byte *)ext->p_cbLineOffset);
  
! #ifdef ECOFF_64
    intern->gp_prologue = bfd_h_get_8 (abfd, (bfd_byte *) ext->p_gp_prologue);
    if (bfd_header_big_endian (abfd))
      {
--- 350,356 ----
    intern->lnHigh        = bfd_h_get_32 (abfd, (bfd_byte *)ext->p_lnHigh);
    intern->cbLineOffset  = ecoff_get_off (abfd, (bfd_byte *)ext->p_cbLineOffset);
  
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
    intern->gp_prologue = bfd_h_get_8 (abfd, (bfd_byte *) ext->p_gp_prologue);
    if (bfd_header_big_endian (abfd))
      {
*************** ecoff_swap_pdr_out (abfd, intern_copy, e
*** 400,406 ****
    bfd_h_put_32 (abfd, intern->lnHigh, (bfd_byte *)ext->p_lnHigh);
    ecoff_put_off (abfd, intern->cbLineOffset, (bfd_byte *)ext->p_cbLineOffset);
  
! #ifdef ECOFF_64
    bfd_h_put_8 (abfd, intern->gp_prologue, (bfd_byte *) ext->p_gp_prologue);
    if (bfd_header_big_endian (abfd))
      {
--- 409,415 ----
    bfd_h_put_32 (abfd, intern->lnHigh, (bfd_byte *)ext->p_lnHigh);
    ecoff_put_off (abfd, intern->cbLineOffset, (bfd_byte *)ext->p_cbLineOffset);
  
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
    bfd_h_put_8 (abfd, intern->gp_prologue, (bfd_byte *) ext->p_gp_prologue);
    if (bfd_header_big_endian (abfd))
      {
*************** ecoff_swap_ext_in (abfd, ext_copy, inter
*** 629,638 ****
    }
    intern->reserved = 0;
  
! #ifdef ECOFF_32
    intern->ifd           = bfd_h_get_signed_16 (abfd, (bfd_byte *)ext->es_ifd);
  #endif
! #ifdef ECOFF_64
    intern->ifd           = bfd_h_get_signed_32 (abfd, (bfd_byte *)ext->es_ifd);
  #endif
  
--- 638,647 ----
    }
    intern->reserved = 0;
  
! #if defined (ECOFF_32) || defined (ECOFF_SIGNED_32)
    intern->ifd           = bfd_h_get_signed_16 (abfd, (bfd_byte *)ext->es_ifd);
  #endif
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
    intern->ifd           = bfd_h_get_signed_32 (abfd, (bfd_byte *)ext->es_ifd);
  #endif
  
*************** ecoff_swap_ext_out (abfd, intern_copy, e
*** 663,669 ****
  			| (intern->cobol_main ? EXT_BITS1_COBOL_MAIN_BIG : 0)
  			| (intern->weakext ? EXT_BITS1_WEAKEXT_BIG : 0));
      ext->es_bits2[0] = 0;
! #ifdef ECOFF_64
      ext->es_bits2[1] = 0;
      ext->es_bits2[2] = 0;
  #endif
--- 672,678 ----
  			| (intern->cobol_main ? EXT_BITS1_COBOL_MAIN_BIG : 0)
  			| (intern->weakext ? EXT_BITS1_WEAKEXT_BIG : 0));
      ext->es_bits2[0] = 0;
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
      ext->es_bits2[1] = 0;
      ext->es_bits2[2] = 0;
  #endif
*************** ecoff_swap_ext_out (abfd, intern_copy, e
*** 672,687 ****
  			| (intern->cobol_main ? EXT_BITS1_COBOL_MAIN_LITTLE : 0)
  			| (intern->weakext ? EXT_BITS1_WEAKEXT_LITTLE : 0));
      ext->es_bits2[0] = 0;
! #ifdef ECOFF_64
      ext->es_bits2[1] = 0;
      ext->es_bits2[2] = 0;
  #endif
    }
  
! #ifdef ECOFF_32
    bfd_h_put_signed_16 (abfd, intern->ifd, (bfd_byte *)ext->es_ifd);
  #endif
! #ifdef ECOFF_64
    bfd_h_put_signed_32 (abfd, intern->ifd, (bfd_byte *)ext->es_ifd);
  #endif
  
--- 681,696 ----
  			| (intern->cobol_main ? EXT_BITS1_COBOL_MAIN_LITTLE : 0)
  			| (intern->weakext ? EXT_BITS1_WEAKEXT_LITTLE : 0));
      ext->es_bits2[0] = 0;
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
      ext->es_bits2[1] = 0;
      ext->es_bits2[2] = 0;
  #endif
    }
  
! #if defined (ECOFF_32) || defined (ECOFF_SIGNED_32)
    bfd_h_put_signed_16 (abfd, intern->ifd, (bfd_byte *)ext->es_ifd);
  #endif
! #if defined (ECOFF_64) || defined (ECOFF_SIGNED_64)
    bfd_h_put_signed_32 (abfd, intern->ifd, (bfd_byte *)ext->es_ifd);
  #endif
  
Index: elf32-mips.c
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf32-mips.c,v
retrieving revision 1.176
diff -p -r1.176 elf32-mips.c
*** elf32-mips.c	2000/05/29 16:45:57	1.176
--- elf32-mips.c	2000/06/20 01:03:07
*************** Foundation, Inc., 59 Temple Place - Suit
*** 40,46 ****
  #include "coff/internal.h"
  #include "coff/ecoff.h"
  #include "coff/mips.h"
! #define ECOFF_32
  #include "ecoffswap.h"
  
  /* This structure is used to hold .got information when linking.  It
--- 40,46 ----
  #include "coff/internal.h"
  #include "coff/ecoff.h"
  #include "coff/mips.h"
! #define ECOFF_SIGNED_32
  #include "ecoffswap.h"
  
  /* This structure is used to hold .got information when linking.  It
Index: elf64-mips.c
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf64-mips.c,v
retrieving revision 1.18
diff -p -r1.18 elf64-mips.c
*** elf64-mips.c	1999/12/10 10:49:53	1.18
--- elf64-mips.c	2000/06/20 01:03:09
*************** Foundation, Inc., 59 Temple Place - Suit
*** 45,51 ****
  #include "coff/ecoff.h"
  /* The 64 bit versions of the mdebug data structures are in alpha.h.  */
  #include "coff/alpha.h"
! #define ECOFF_64
  #include "ecoffswap.h"
  
  static void mips_elf64_swap_reloc_in
--- 45,51 ----
  #include "coff/ecoff.h"
  /* The 64 bit versions of the mdebug data structures are in alpha.h.  */
  #include "coff/alpha.h"
! #define ECOFF_SIGNED_64
  #include "ecoffswap.h"
  
  static void mips_elf64_swap_reloc_in

Re: [rfc] For mips, sign-extended ecoff offsets

[Ulf Carlsson]

Hi Andrew,

 > > > The attatched patch changes the MIPS ELF32 backend so that it is more
 > > > likely to return a sign-extended offset.  At present the ELF backend
 > > > returns sign-extended symbol table values but not sign extended debug
 > > > information.
 > > 
 > > Hi Andrew,
 > >    Would it be better to just change ecoff_swap_sym_in?  It seems like
 > > this would achieve what you want, and not risk breaking quite so much.
 > > I'm worried about what happens if things like PDR.adr get changed from
 > > 0xa0000000 to 0xffffffffa0000000.
 > 
 > Thats why I'm asking :-) Remember though, on the MIPS platform, if
 > ``PDR.adr'' is an address then, the canonical form of the value
 > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. 
 > GDB and BFD have, for too many years, been bribed and cajoled into
 > perpetuated the lie that MIPS doesn't sign extend addresses.   GDB's now
 > decided to come clean on this matter (and purge an amazing amount of
 > bogus code :-).

On a 64-bit MIPS processor 32-bit addresses are of course sign
extended, but this shouldn't concern the 32-bit BFD backend for MIPS
in any way.  Whether we sign extend the addresses or not shouldn't
make any difference except in our internal representation of the
bfd_vma.  I may be wrong though!

Ulf

Re: [rfc] For mips, sign-extended ecoff offsets

[Alan Modra]

On Tue, 20 Jun 2000, Andrew Cagney wrote:

> > I'm worried about what happens if things like PDR.adr get changed from
> > 0xa0000000 to 0xffffffffa0000000.
> 
> Thats why I'm asking :-) Remember though, on the MIPS platform, if
> ``PDR.adr'' is an address then, the canonical form of the value
> ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. 
> GDB and BFD have, for too many years, been bribed and cajoled into
> perpetuated the lie that MIPS doesn't sign extend addresses.   GDB's now
> decided to come clean on this matter (and purge an amazing amount of
> bogus code :-).

Well, it's the likelihood of other "bogus code" existing in binutils that
assumes addresses are _not_ sign extended that worries me.  If you work to
the "You break it, you fix it" rule, then you may be taking on quite a bit
of work :-)

> Any way I've attached a revised patch.  I wasn't ruthless enough the
> first time....  With this revision the linker appears to work :-) 
> Testing is continuing.

There's an ECOF_ typo still in a comment.

> I guess the question for BFD people is, is this the correct approach to
> fixing this bug?

I'd like to hear Ian's comments on this before you check it in.

Regards, Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: [rfc] For mips, sign-extended ecoff offsets

[Alan Modra]

On Mon, 19 Jun 2000, Ulf Carlsson wrote:

> On a 64-bit MIPS processor 32-bit addresses are of course sign
> extended, but this shouldn't concern the 32-bit BFD backend for MIPS
> in any way.  Whether we sign extend the addresses or not shouldn't
> make any difference except in our internal representation of the
> bfd_vma.  I may be wrong though!

It doesn't make much difference if bfd_vma is only 32-bits (ie. BFD_64 is
not set)  Where you get into trouble is with targets that are generally
32-bit, but you may be using 64-bit bfd_vma types due to --enable-targets

-- 
Linuxcare.  Support for the Revolution.

Re: [rfc] For mips, sign-extended ecoff offsets

[Andrew Cagney]

Ulf Carlsson wrote:
> 
> Hi Andrew,
> 
>  > > > The attatched patch changes the MIPS ELF32 backend so that it is more
>  > > > likely to return a sign-extended offset.  At present the ELF backend
>  > > > returns sign-extended symbol table values but not sign extended debug
>  > > > information.
>  > >
>  > > Hi Andrew,
>  > >    Would it be better to just change ecoff_swap_sym_in?  It seems like
>  > > this would achieve what you want, and not risk breaking quite so much.
>  > > I'm worried about what happens if things like PDR.adr get changed from
>  > > 0xa0000000 to 0xffffffffa0000000.
>  >
>  > Thats why I'm asking :-) Remember though, on the MIPS platform, if
>  > ``PDR.adr'' is an address then, the canonical form of the value
>  > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000.
>  > GDB and BFD have, for too many years, been bribed and cajoled into
>  > perpetuated the lie that MIPS doesn't sign extend addresses.   GDB's now
>  > decided to come clean on this matter (and purge an amazing amount of
>  > bogus code :-).
> 
> On a 64-bit MIPS processor 32-bit addresses are of course sign
> extended, but this shouldn't concern the 32-bit BFD backend for MIPS
> in any way.  Whether we sign extend the addresses or not shouldn't
> make any difference except in our internal representation of the
> bfd_vma.  I may be wrong though!

FYI, it certainly makes a mess of the symbol table lookup code.  At one
end of GDB the MIPS processor (with those 64 bit registers being used in
the n32 ABI say) is providing sign extended register values while at the
other end BFD is giving GDB, er, inconsistent values.

	Andrew

Re: [rfc] For mips, sign-extended ecoff offsets

[Andrew Cagney]

Alan Modra wrote:
> 
> On Tue, 20 Jun 2000, Andrew Cagney wrote:
> 
> > > I'm worried about what happens if things like PDR.adr get changed from
> > > 0xa0000000 to 0xffffffffa0000000.
> >
> > Thats why I'm asking :-) Remember though, on the MIPS platform, if
> > ``PDR.adr'' is an address then, the canonical form of the value
> > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000.
> > GDB and BFD have, for too many years, been bribed and cajoled into
> > perpetuated the lie that MIPS doesn't sign extend addresses.   GDB's now
> > decided to come clean on this matter (and purge an amazing amount of
> > bogus code :-).
> 
> Well, it's the likelihood of other "bogus code" existing in binutils that
> assumes addresses are _not_ sign extended that worries me.  If you work to
> the "You break it, you fix it" rule, then you may be taking on quite a bit
> of work :-)

I can help to an extent, however, to be honest, I'm having enough fun
just re-stablizing the the GDB side of the MIPS.  Consequently I'd be
focusing on GDB specific problems.  People on the BFD/MIPS side will
need to be willing to help if there is fallout.

> > Any way I've attached a revised patch.  I wasn't ruthless enough the
> > first time....  With this revision the linker appears to work :-)
> > Testing is continuing.
> 
> There's an ECOF_ typo still in a comment.

Thanks.

> > I guess the question for BFD people is, is this the correct approach to
> > fixing this bug?
> 
> I'd like to hear Ian's comments on this before you check it in.

Ian has a long memory (Nick does to :-) and both would be very familar
with the underlying problems and the very long history that is behind
this :-)

	Andrew

Re: [rfc] For mips, sign-extended ecoff offsets

[Geoff Keating]

> From: Ulf Carlsson <ulfc@calypso.engr.sgi.com>
> Date: Mon, 19 Jun 2000 18:45:44 -0700 (PDT)

> On a 64-bit MIPS processor 32-bit addresses are of course sign
> extended, but this shouldn't concern the 32-bit BFD backend for MIPS
> in any way.  Whether we sign extend the addresses or not shouldn't
> make any difference except in our internal representation of the
> bfd_vma.  I may be wrong though!

The 64-bit MIPS machines often use the 32-bit ELF format, typically
because they have 32-bit memory addresses (I forget whether trying to
access 0x0000000087654321 gives you 0xffffffff87654321 or a trap).

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: [rfc] For mips, sign-extended ecoff offsets

[Ian Lance Taylor]

   Date: Tue, 20 Jun 2000 11:50:26 +1000 (EST)
   From: Alan Modra <alan@linuxcare.com.au>

   > > I'm worried about what happens if things like PDR.adr get changed from
   > > 0xa0000000 to 0xffffffffa0000000.
   > 
   > Thats why I'm asking :-) Remember though, on the MIPS platform, if
   > ``PDR.adr'' is an address then, the canonical form of the value
   > ``0xa0000000'' obtained from an elf32 binary is 0xffffffffa00000000. 
   > GDB and BFD have, for too many years, been bribed and cajoled into
   > perpetuated the lie that MIPS doesn't sign extend addresses.   GDB's now
   > decided to come clean on this matter (and purge an amazing amount of
   > bogus code :-).


   > I guess the question for BFD people is, is this the correct approach to
   > fixing this bug?

   I'd like to hear Ian's comments on this before you check it in.

This is all due to a long-ago decision to ship support for a 64-bit
MIPS chip using a 32-bit MIPS target.  I think that sign extending
pdr.ADR is probably right, since that is how 32 bit addresses are
treated by the relocation routines.  But the real fix is to use a
64-bit MIPS target.

Ian

Re: [rfc] For mips, sign-extended ecoff offsets

[Ian Lance Taylor]

   Date: Mon, 19 Jun 2000 20:07:59 -0700
   From: Geoff Keating <geoffk@cygnus.com>

   > From: Ulf Carlsson <ulfc@calypso.engr.sgi.com>
   > Date: Mon, 19 Jun 2000 18:45:44 -0700 (PDT)

   > On a 64-bit MIPS processor 32-bit addresses are of course sign
   > extended, but this shouldn't concern the 32-bit BFD backend for MIPS
   > in any way.  Whether we sign extend the addresses or not shouldn't
   > make any difference except in our internal representation of the
   > bfd_vma.  I may be wrong though!

   The 64-bit MIPS machines often use the 32-bit ELF format, typically
   because they have 32-bit memory addresses (I forget whether trying to
   access 0x0000000087654321 gives you 0xffffffff87654321 or a trap).

I think the real reason this happens is historical--because we didn't
have a 64-bit MIPS format when we started supporting 64-bit MIPS
chips.  I don't think there is any particularly legitimate reason to
use a 32-bit format for a 64-bit chip.

Ian

Re: [rfc] For mips, sign-extended ecoff offsets

[Geoff Keating]

> From: Ulf Carlsson <ulfc@calypso.engr.sgi.com>
> Date: Mon, 19 Jun 2000 20:48:56 -0700 (PDT)
> 
>  > > On a 64-bit MIPS processor 32-bit addresses are of course sign
>  > > extended, but this shouldn't concern the 32-bit BFD backend for MIPS
>  > > in any way.  Whether we sign extend the addresses or not shouldn't
>  > > make any difference except in our internal representation of the
>  > > bfd_vma.  I may be wrong though!
>  > 
>  > The 64-bit MIPS machines often use the 32-bit ELF format, typically
>  > because they have 32-bit memory addresses (I forget whether trying to
>  > access 0x0000000087654321 gives you 0xffffffff87654321 or a trap).
> 
> We always have 0x87654321 in the 32-bit ELF file.  It probably doesn't
> matter what our internal representation is since we'll drop the upper
> 32 bits when we write the ELF file in either case and the address will
> be properly sign extended again when the ELF file is loaded.

A similar argument was used originally to justify not forcing BFD to
do the right thing.

An example where it does matter is when you try to work out whether
a 32-bit pc-relative operand can hold the offset from 0x10000000 to
0xA0000000, or whether there should be overflow.

In GDB, it matters whenever you are comparing a value in a register to
an address in the object file.
-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: [rfc] For mips, sign-extended ecoff offsets

[Andrew Cagney]

Ian Lance Taylor wrote:

>    I'd like to hear Ian's comments on this before you check it in.
> 
> This is all due to a long-ago decision to ship support for a 64-bit
> MIPS chip using a 32-bit MIPS target.  I think that sign extending
> pdr.ADR is probably right, since that is how 32 bit addresses are
> treated by the relocation routines.

Yes.

>  But the real fix is to use a
> 64-bit MIPS target.

Kind of :-)  GDB can now be built to support (embedded only mind) the
debugging of a fairly arbitrary MIPS ABI on 64 bit MIPS targets.  For
instance, a single GDB executable can debug both ``gcc -mips2'' and
``gcc ...'' executables running on a 64 bit vr5000.  It might even
eventually support that behavour under IRIX :-)

Implementing this cleanly relies 32 bit MIPS addresses always being
correctly sign extended.  At present they are not and things are
suffering for it :-)

	enjoy,
		Andrew

Re: [rfc] For mips, sign-extended ecoff offsets

[Ian Lance Taylor]

   Date: Fri, 23 Jun 2000 17:27:02 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   > This is all due to a long-ago decision to ship support for a 64-bit
   > MIPS chip using a 32-bit MIPS target.  I think that sign extending
   > pdr.ADR is probably right, since that is how 32 bit addresses are
   > treated by the relocation routines.

   Yes.

   >  But the real fix is to use a
   > 64-bit MIPS target.

   Kind of :-)  GDB can now be built to support (embedded only mind) the
   debugging of a fairly arbitrary MIPS ABI on 64 bit MIPS targets.  For
   instance, a single GDB executable can debug both ``gcc -mips2'' and
   ``gcc ...'' executables running on a 64 bit vr5000.  It might even
   eventually support that behavour under IRIX :-)

   Implementing this cleanly relies 32 bit MIPS addresses always being
   correctly sign extended.  At present they are not and things are
   suffering for it :-)

I don't understand that.  When gdb is debugging a 32 bit target, such
as gcc -mips2, it should handle all target addresses as 32 bit values.
Anything else would be a host/target confusion.  Sign extension or
lack thereof should be irrelevant.

The only issue here is that, for historical reasons, some 64 bit
targets use a 32 bit object file format.  If each 64 bit target used a
64 bit object file format, all would be well.

Ian

Re: [rfc] For mips, sign-extended ecoff offsets

[Ralf Baechle]

On Mon, Jun 19, 2000 at 08:41:02PM -0700, Ian Lance Taylor wrote:

>    > On a 64-bit MIPS processor 32-bit addresses are of course sign
>    > extended, but this shouldn't concern the 32-bit BFD backend for MIPS
>    > in any way.  Whether we sign extend the addresses or not shouldn't
>    > make any difference except in our internal representation of the
>    > bfd_vma.  I may be wrong though!
> 
>    The 64-bit MIPS machines often use the 32-bit ELF format, typically
>    because they have 32-bit memory addresses (I forget whether trying to
>    access 0x0000000087654321 gives you 0xffffffff87654321 or a trap).
> 
> I think the real reason this happens is historical--because we didn't
> have a 64-bit MIPS format when we started supporting 64-bit MIPS
> chips.  I don't think there is any particularly legitimate reason to
> use a 32-bit format for a 64-bit chip.

We do that for Linux/MIPS64.  Originally I came up with this due to the
incredible brokeness of ld for 64-bit MIPS ELF.  It allows us to generate
64-bit code that is more compact than standard 64-bit code because dla get
expanded to only 2 instructions like in 32-bit code.  All it takes is
proper placement of the code into the 32-bit address space.  We still
have kept the advantages of 64-bit code.

  Ralf

Re: [rfc] For mips, sign-extended ecoff offsets

[Andrew Cagney]

(I've been away for a week, sorry)

Ian Lance Taylor wrote:
> 
>    >  But the real fix is to use a
>    > 64-bit MIPS target.
> 
>    Kind of :-)  GDB can now be built to support (embedded only mind) the
>    debugging of a fairly arbitrary MIPS ABI on 64 bit MIPS targets.  For
>    instance, a single GDB executable can debug both ``gcc -mips2'' and
>    ``gcc ...'' executables running on a 64 bit vr5000.  It might even
>    eventually support that behavour under IRIX :-)
> 
>    Implementing this cleanly relies 32 bit MIPS addresses always being
>    correctly sign extended.  At present they are not and things are
>    suffering for it :-)
> 
> I don't understand that.  When gdb is debugging a 32 bit target, such
> as gcc -mips2, it should handle all target addresses as 32 bit values.
> Anything else would be a host/target confusion.  Sign extension or
> lack thereof should be irrelevant.

GDB has two things to contend with:

	o	the program - gcc -mips2 (32 bit) (ABI)

	o	the physical target - 32 or 64 bit (ISA)

When debugging a 32 bit program on what is a 64 bit physical target, GDB
could communicate using either 32 or 64 bit values/addresses.  GDB
started out by trying to follow the ABI and talk 32bit to 64 bit
physical targets.

It turns out this was a bad idea.  Instead, GDB should always talk
64bits to 64 bit physical targets.  This simplifies both the embedded
stub and GDBs internals.  In the case of GDB, the simplification comes
from replacing scrambled code trying to directly convert
symbolic-address <-> target-address with two clearly separate
translations - symbol<->canonical and cannonical<->target address.

> The only issue here is that, for historical reasons, some 64 bit
> targets use a 32 bit object file format.  If each 64 bit target used a
> 64 bit object file format, all would be well.

Yes, for the MIPS that is how things started.

Since then, however, things have evolved and now people are trying to do
things like build single GDB binaries that can debug (on IRIX) any of
n32, o32 and o64.

	enjoy,
		Andrew