Test for 32/64 bit object file?

Test for 32/64 bit object file?

[Andrew Cagney]

Hello,

Is there a way of determining if an object file is 32 or 64 bit?  (eg
elf32/elf64, aout32 vs aout64).
Perhaphs bfd_arch_bits_per_address(ABFD) is correct?

	Andrew

Re: Test for 32/64 bit object file?

[Ian Lance Taylor]

   Date: Wed, 17 Nov 1999 07:20:16 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   Is there a way of determining if an object file is 32 or 64 bit?  (eg
   elf32/elf64, aout32 vs aout64).

Why do you want to know?  I don't mean to be snide; it's just that
that distinction usually isn't interesting.

   Perhaphs bfd_arch_bits_per_address(ABFD) is correct?

That will tell you whether the CPU uses 32 bits in an address or 64
bits in an address.  It's not the same as elf32 vs. elf64, but it may
be what you need to know.

Ian

Re: Test for 32/64 bit object file?

[Andrew Cagney]

Ian Lance Taylor wrote:
> 
>    Date: Wed, 17 Nov 1999 07:20:16 +1100
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    Is there a way of determining if an object file is 32 or 64 bit?  (eg
>    elf32/elf64, aout32 vs aout64).
> 
> Why do you want to know?  I don't mean to be snide; it's just that
> that distinction usually isn't interesting.

never a silly question :-)

>    Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
> 
> That will tell you whether the CPU uses 32 bits in an address or 64
> bits in an address.  It's not the same as elf32 vs. elf64, but it may
> be what you need to know.

GDB encounters situtations (c.f. assorted mips targets) where the object
file contains 32 bit addresses but the target has a 64 bit address
space.  The 32 address values being implicitly zero or sign extended to
64 bits.  GDB needs to know what the object file format assumed (or
didn't in some case) is doing so that it can correctly do things like
compares.

I also suspect that the sprintf_vma() et.al. macro's should format the
address according to the BFD object file address size rather than BFD64.

	enjoy,
		Andrew

Re: Test for 32/64 bit object file?

[Ian Lance Taylor]

   Date: Wed, 17 Nov 1999 09:00:02 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   >    Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
   > 
   > That will tell you whether the CPU uses 32 bits in an address or 64
   > bits in an address.  It's not the same as elf32 vs. elf64, but it may
   > be what you need to know.

   GDB encounters situtations (c.f. assorted mips targets) where the object
   file contains 32 bit addresses but the target has a 64 bit address
   space.  The 32 address values being implicitly zero or sign extended to
   64 bits.  GDB needs to know what the object file format assumed (or
   didn't in some case) is doing so that it can correctly do things like
   compares.

I don't think there is any general purpose approach to this.  The 32
bit MIPS targets act idiosyncratically, because we needed to support
64 bit MIPS processors before we supported the 64 bit MIPS ELF object
file format.  I don't think any other target acts the way they do.

Note that you can't use bfd_arch_bits_per_address to determine the
size of an address in a MIPS ELF object file.

BFD does know whether a target requires a 64 bit bfd_vma, which is
about as close as I can see to what you are asking for.  However, this
information is stored only in bfd/configure.in, in the setting of the
shell variable target64.

For the special case of an ELF target, you can look at arch_size field
of the size_info structure.  BFD doesn't currently provide any
interface for other programs to look at that field.

   I also suspect that the sprintf_vma() et.al. macro's should format the
   address according to the BFD object file address size rather than BFD64.

BFD64 defines the size of a bfd_vma, and sprintf_vma doesn't check an
object file.  If it did, I think bfd_arch_bits_per_address would be
the right thing to check.

Ian

Re: Test for 32/64 bit object file?

[Andrew Cagney]

Ian Lance Taylor wrote:
> 
>    Date: Wed, 17 Nov 1999 09:00:02 +1100
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    >    Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
>    >
>    > That will tell you whether the CPU uses 32 bits in an address or 64
>    > bits in an address.  It's not the same as elf32 vs. elf64, but it may
>    > be what you need to know.
> 
>    GDB encounters situtations (c.f. assorted mips targets) where the object
>    file contains 32 bit addresses but the target has a 64 bit address
>    space.  The 32 address values being implicitly zero or sign extended to
>    64 bits.  GDB needs to know what the object file format assumed (or
>    didn't in some case) is doing so that it can correctly do things like
>    compares.
> 
> I don't think there is any general purpose approach to this.  The 32
> bit MIPS targets act idiosyncratically, because we needed to support
> 64 bit MIPS processors before we supported the 64 bit MIPS ELF object
> file format.  I don't think any other target acts the way they do.

If we consider the MIPS idiosyncratic then can
bfd_arch_bits_per_address() be considered reliable for non mips/elf
targets?

For the mips GDB could always handle that as a special case:

	o	for an elf target check the elf info

	o	for other targets just assume
		bfd_arch_bits_per_address() is correct

> Note that you can't use bfd_arch_bits_per_address to determine the
> size of an address in a MIPS ELF object file.

per above, what about for non-mips targets?

> BFD does know whether a target requires a 64 bit bfd_vma, which is
> about as close as I can see to what you are asking for.  However, this
> information is stored only in bfd/configure.in, in the setting of the
> shell variable target64.

I think the macro ARCH_SIZE defined/used by some targets contains what
I'm looking for.
Is it worth extending BFD (struct bfd_target) to include that
information somewhere?  (Grubbing through the code it doesn't look easy
- many changes to many files).

>    I also suspect that the sprintf_vma() et.al. macro's should format the
>    address according to the BFD object file address size rather than BFD64.
> 
> BFD64 defines the size of a bfd_vma, and sprintf_vma doesn't check an
> object file.  If it did, I think bfd_arch_bits_per_address would be
> the right thing to check.

True.

	enjoy,
		Andrew

Re: Test for 32/64 bit object file?

[Ian Lance Taylor]

   Date: Wed, 17 Nov 1999 12:47:58 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   >    GDB encounters situtations (c.f. assorted mips targets) where the object
   >    file contains 32 bit addresses but the target has a 64 bit address
   >    space.  The 32 address values being implicitly zero or sign extended to
   >    64 bits.  GDB needs to know what the object file format assumed (or
   >    didn't in some case) is doing so that it can correctly do things like
   >    compares.
   > 
   > I don't think there is any general purpose approach to this.  The 32
   > bit MIPS targets act idiosyncratically, because we needed to support
   > 64 bit MIPS processors before we supported the 64 bit MIPS ELF object
   > file format.  I don't think any other target acts the way they do.

   If we consider the MIPS idiosyncratic then can
   bfd_arch_bits_per_address() be considered reliable for non mips/elf
   targets?

That will always get you the size of an address of the CPU.  There is
no particular reason to assume that that is the size of an address
stored in the object file.

I don't know of any other case where it is different.  But I'm not
going to promise that there will never be another case.

   > BFD does know whether a target requires a 64 bit bfd_vma, which is
   > about as close as I can see to what you are asking for.  However, this
   > information is stored only in bfd/configure.in, in the setting of the
   > shell variable target64.

   I think the macro ARCH_SIZE defined/used by some targets contains what
   I'm looking for.
   Is it worth extending BFD (struct bfd_target) to include that
   information somewhere?  (Grubbing through the code it doesn't look easy
   - many changes to many files).

Yes, ARCH_SIZE is probably approximately what you are asking for.  But
it isn't used by every backend.

Ian

Re: Test for 32/64 bit object file?

[Richard Henderson]

On Wed, Nov 17, 1999 at 09:00:02AM +1100, Andrew Cagney wrote:
> GDB encounters situtations (c.f. assorted mips targets) where the object
> file contains 32 bit addresses but the target has a 64 bit address
> space.  The 32 address values being implicitly zero or sign extended to
> 64 bits.  GDB needs to know what the object file format assumed (or
> didn't in some case) is doing so that it can correctly do things like
> compares.

I was thinking something like this might work.  The idea is to 
have bfd_vma be 64-bits (which it already is), and have the BFD
sign extend the values it finds in the elf32 object files.  This
mirrors what we do for e.g. R_MIPS_64 in such a case, and thus
what a run-time loader ought to be doing as well.  

GDB should continue to use complete 64-bit addresses, since the
entire address space is potentially valid at runtime.

Comments?


r~


	* elf-bfd.h (struct elf_backend_data): Reorder collect and 
	type_change_ok; add sign_extend_vma.
	* elf32-mips.c (elf_backend_sign_extend_vma): Define.
	* elfcode.h (elf_swap_symbol_in): Mind be->sign_extend_vma.
	(elf_swap_shdr_in, elf_swap_phdr_in): Likewise.
	* elfxx-target.h (elf_backend_sign_extend_vma): Default.
	(elfNN_bed): Follow struture changes.

Index: elf-bfd.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf-bfd.h,v
retrieving revision 1.55
diff -c -p -d -r1.55 elf-bfd.h
*** elf-bfd.h	1999/09/14 01:13:01	1.55
--- elf-bfd.h	1999/11/17 02:26:58
*************** struct elf_backend_data
*** 329,346 ****
    /* The maximum page size for this backend.  */
    bfd_vma maxpagesize;
  
-   /* This is true if the linker should act like collect and gather
-      global constructors and destructors by name.  This is true for
-      MIPS ELF because the Irix 5 tools can not handle the .init
-      section.  */
-   boolean collect;
- 
-   /* This is true if the linker should ignore changes to the type of a
-      symbol.  This is true for MIPS ELF because some Irix 5 objects
-      record undefined functions as STT_OBJECT although the definitions
-      are STT_FUNC.  */
-   boolean type_change_ok;
- 
    /* A function to translate an ELF RELA relocation to a BFD arelent
       structure.  */
    void (*elf_info_to_howto) PARAMS ((bfd *, arelent *,
--- 329,334 ----
*************** struct elf_backend_data
*** 600,605 ****
--- 588,605 ----
    bfd_vma got_header_size;
    bfd_vma plt_header_size;
  
+   /* This is true if the linker should act like collect and gather
+      global constructors and destructors by name.  This is true for
+      MIPS ELF because the Irix 5 tools can not handle the .init
+      section.  */
+   unsigned collect : 1;
+ 
+   /* This is true if the linker should ignore changes to the type of a
+      symbol.  This is true for MIPS ELF because some Irix 5 objects
+      record undefined functions as STT_OBJECT although the definitions
+      are STT_FUNC.  */
+   unsigned type_change_ok : 1;
+ 
    /* Whether the backend may use REL relocations.  (Some backends use
       both REL and RELA relocations, and this flag is set for those
       backends.)  */
*************** struct elf_backend_data
*** 616,621 ****
--- 616,625 ----
       and the backend wants RELA relocations for a particular
       section.  */
    unsigned default_use_rela_p : 1;
+ 
+   /* True if addresses "naturally" sign extend.  This is used when
+      swapping in from Elf32 when BFD64.  */
+   unsigned sign_extend_vma : 1;
  
    unsigned want_got_plt : 1;
    unsigned plt_readonly : 1;
Index: elf32-mips.c
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elf32-mips.c,v
retrieving revision 1.165
diff -c -p -d -r1.165 elf32-mips.c
*** elf32-mips.c	1999/10/22 15:51:39	1.165
--- elf32-mips.c	1999/11/17 02:26:58
*************** static const struct ecoff_debug_swap mip
*** 9114,9119 ****
--- 9114,9120 ----
  #define elf_backend_collect		true
  #define elf_backend_type_change_ok	true
  #define elf_backend_can_gc_sections	true
+ #define elf_backend_sign_extend_vma	true
  #define elf_info_to_howto		mips_info_to_howto_rela
  #define elf_info_to_howto_rel		mips_info_to_howto_rel
  #define elf_backend_sym_is_global	mips_elf_sym_is_global
Index: elfcode.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elfcode.h,v
retrieving revision 1.239
diff -c -p -d -r1.239 elfcode.h
*** elfcode.h	1999/09/14 01:16:13	1.239
--- elfcode.h	1999/11/17 02:26:58
*************** elf_swap_symbol_in (abfd, src, dst)
*** 205,212 ****
       const Elf_External_Sym *src;
       Elf_Internal_Sym *dst;
  {
    dst->st_name = bfd_h_get_32 (abfd, (bfd_byte *) src->st_name);
!   dst->st_value = get_word (abfd, (bfd_byte *) src->st_value);
    dst->st_size = get_word (abfd, (bfd_byte *) src->st_size);
    dst->st_info = bfd_h_get_8 (abfd, (bfd_byte *) src->st_info);
    dst->st_other = bfd_h_get_8 (abfd, (bfd_byte *) src->st_other);
--- 205,217 ----
       const Elf_External_Sym *src;
       Elf_Internal_Sym *dst;
  {
+   int signed_vma = get_elf_backend_data (abfd)->sign_extend_vma;
+ 
    dst->st_name = bfd_h_get_32 (abfd, (bfd_byte *) src->st_name);
!   if (signed_vma)
!     dst->st_value = get_signed_word (abfd, (bfd_byte *) src->st_value);
!   else
!     dst->st_value = get_word (abfd, (bfd_byte *) src->st_value);
    dst->st_size = get_word (abfd, (bfd_byte *) src->st_size);
    dst->st_info = bfd_h_get_8 (abfd, (bfd_byte *) src->st_info);
    dst->st_other = bfd_h_get_8 (abfd, (bfd_byte *) src->st_other);
*************** elf_swap_shdr_in (abfd, src, dst)
*** 293,302 ****
       const Elf_External_Shdr *src;
       Elf_Internal_Shdr *dst;
  {
    dst->sh_name = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_name);
    dst->sh_type = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_type);
    dst->sh_flags = get_word (abfd, (bfd_byte *) src->sh_flags);
!   dst->sh_addr = get_word (abfd, (bfd_byte *) src->sh_addr);
    dst->sh_offset = get_word (abfd, (bfd_byte *) src->sh_offset);
    dst->sh_size = get_word (abfd, (bfd_byte *) src->sh_size);
    dst->sh_link = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_link);
--- 298,312 ----
       const Elf_External_Shdr *src;
       Elf_Internal_Shdr *dst;
  {
+   int signed_vma = get_elf_backend_data (abfd)->sign_extend_vma;
+ 
    dst->sh_name = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_name);
    dst->sh_type = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_type);
    dst->sh_flags = get_word (abfd, (bfd_byte *) src->sh_flags);
!   if (signed_vma)
!     dst->sh_addr = get_signed_word (abfd, (bfd_byte *) src->sh_addr);
!   else
!     dst->sh_addr = get_word (abfd, (bfd_byte *) src->sh_addr);
    dst->sh_offset = get_word (abfd, (bfd_byte *) src->sh_offset);
    dst->sh_size = get_word (abfd, (bfd_byte *) src->sh_size);
    dst->sh_link = bfd_h_get_32 (abfd, (bfd_byte *) src->sh_link);
*************** elf_swap_phdr_in (abfd, src, dst)
*** 339,349 ****
       const Elf_External_Phdr *src;
       Elf_Internal_Phdr *dst;
  {
    dst->p_type = bfd_h_get_32 (abfd, (bfd_byte *) src->p_type);
    dst->p_flags = bfd_h_get_32 (abfd, (bfd_byte *) src->p_flags);
    dst->p_offset = get_word (abfd, (bfd_byte *) src->p_offset);
!   dst->p_vaddr = get_word (abfd, (bfd_byte *) src->p_vaddr);
!   dst->p_paddr = get_word (abfd, (bfd_byte *) src->p_paddr);
    dst->p_filesz = get_word (abfd, (bfd_byte *) src->p_filesz);
    dst->p_memsz = get_word (abfd, (bfd_byte *) src->p_memsz);
    dst->p_align = get_word (abfd, (bfd_byte *) src->p_align);
--- 349,369 ----
       const Elf_External_Phdr *src;
       Elf_Internal_Phdr *dst;
  {
+   int signed_vma = get_elf_backend_data (abfd)->sign_extend_vma;
+ 
    dst->p_type = bfd_h_get_32 (abfd, (bfd_byte *) src->p_type);
    dst->p_flags = bfd_h_get_32 (abfd, (bfd_byte *) src->p_flags);
    dst->p_offset = get_word (abfd, (bfd_byte *) src->p_offset);
!   if (signed_vma)
!     {
!       dst->p_vaddr = get_signed_word (abfd, (bfd_byte *) src->p_vaddr);
!       dst->p_paddr = get_signed_word (abfd, (bfd_byte *) src->p_paddr);
!     }
!   else
!     {
!       dst->p_vaddr = get_word (abfd, (bfd_byte *) src->p_vaddr);
!       dst->p_paddr = get_word (abfd, (bfd_byte *) src->p_paddr);
!     }
    dst->p_filesz = get_word (abfd, (bfd_byte *) src->p_filesz);
    dst->p_memsz = get_word (abfd, (bfd_byte *) src->p_memsz);
    dst->p_align = get_word (abfd, (bfd_byte *) src->p_align);
Index: elfxx-target.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elfxx-target.h,v
retrieving revision 1.42
diff -c -p -d -r1.42 elfxx-target.h
*** elfxx-target.h	1999/07/19 07:54:12	1.42
--- elfxx-target.h	1999/11/17 02:26:59
*************** Foundation, Inc., 59 Temple Place - Suit
*** 332,337 ****
--- 332,341 ----
  #define elf_backend_size_info _bfd_elfNN_size_info
  #endif
  
+ #ifndef elf_backend_sign_extend_vma
+ #define elf_backend_sign_extend_vma 0
+ #endif
+ 
  extern const struct elf_size_info _bfd_elfNN_size_info;
  
  static CONST struct elf_backend_data elfNN_bed =
*************** static CONST struct elf_backend_data elf
*** 339,346 ****
    ELF_ARCH,			/* arch */
    ELF_MACHINE_CODE,		/* elf_machine_code */
    ELF_MAXPAGESIZE,		/* maxpagesize */
-   elf_backend_collect,
-   elf_backend_type_change_ok,
    elf_info_to_howto,
    elf_info_to_howto_rel,
    elf_backend_sym_is_global,
--- 343,348 ----
*************** static CONST struct elf_backend_data elf
*** 376,384 ****
--- 378,389 ----
    elf_backend_got_symbol_offset,
    elf_backend_got_header_size,
    elf_backend_plt_header_size,
+   elf_backend_collect,
+   elf_backend_type_change_ok,
    elf_backend_may_use_rel_p,
    elf_backend_may_use_rela_p,
    elf_backend_default_use_rela_p,
+   elf_backend_sign_extend_vma,
    elf_backend_want_got_plt,
    elf_backend_plt_readonly,
    elf_backend_want_plt_sym,

Re: Test for 32/64 bit object file?

[Andrew Cagney]

Ian Lance Taylor wrote:
> 
>    Date: Wed, 17 Nov 1999 12:47:58 +1100
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    >    GDB encounters situtations (c.f. assorted mips targets) where the object
>    >    file contains 32 bit addresses but the target has a 64 bit address
>    >    space.  The 32 address values being implicitly zero or sign extended to
>    >    64 bits.  GDB needs to know what the object file format assumed (or
>    >    didn't in some case) is doing so that it can correctly do things like
>    >    compares.
>    >
>    > I don't think there is any general purpose approach to this.  The 32
>    > bit MIPS targets act idiosyncratically, because we needed to support
>    > 64 bit MIPS processors before we supported the 64 bit MIPS ELF object
>    > file format.  I don't think any other target acts the way they do.
> 
>    If we consider the MIPS idiosyncratic then can
>    bfd_arch_bits_per_address() be considered reliable for non mips/elf
>    targets?
> 
> That will always get you the size of an address of the CPU.  There is
> no particular reason to assume that that is the size of an address
> stored in the object file.
> 
> I don't know of any other case where it is different.  But I'm not
> going to promise that there will never be another case.

OK, initially GDB should do this. (With big comments saying that it
could get it wrong :-).

> 
>    > BFD does know whether a target requires a 64 bit bfd_vma, which is
>    > about as close as I can see to what you are asking for.  However, this
>    > information is stored only in bfd/configure.in, in the setting of the
>    > shell variable target64.
> 
>    I think the macro ARCH_SIZE defined/used by some targets contains what
>    I'm looking for.
>    Is it worth extending BFD (struct bfd_target) to include that
>    information somewhere?  (Grubbing through the code it doesn't look easy
>    - many changes to many files).
> 
> Yes, ARCH_SIZE is probably approximately what you are asking for.  But
> it isn't used by every backend.

And this should be done if the problem turns out to be more serious.

	Andrew