[Patch]: Fix bfd_get_arch_size for non-ELF targets

[Patch]: Fix bfd_get_arch_size for non-ELF targets

[Tristan Gingold]

Hello,

currently bfd_get_arch_size always returns -1 on non-ELF targets. One visible consequence is
the output of objdump -h: the headline is printed for 64 bit vma, even if the vma are 32 bit wide
(and printed using 8 chars).

With this patch, bfd_get_arch_size returns bfd_arch_bits_per_address on non-ELF targets.

I don't know if it is necessary to handle ELF differently here.  It's already the case for
is32bit.

Ok for trunk ?

Tristan.

bfd/
	* bfd.c (bfd_get_arch_size): Default is taken from arch.


diff --git a/bfd/bfd.c b/bfd/bfd.c
index 6b00592..512abc4 100644
--- a/bfd/bfd.c
+++ b/bfd/bfd.c
@@ -1087,7 +1087,7 @@ bfd_get_arch_size (bfd *abfd)
   if (abfd->xvec->flavour == bfd_target_elf_flavour)
     return get_elf_backend_data (abfd)->s->arch_size;
 
-  return -1;
+  return bfd_arch_bits_per_address (abfd);
 }
 
 /*

Re: [Patch]: Fix bfd_get_arch_size for non-ELF targets

[Alan Modra]

On Thu, Apr 03, 2014 at 12:09:04PM +0200, Tristan Gingold wrote:
> --- a/bfd/bfd.c
> +++ b/bfd/bfd.c
> @@ -1087,7 +1087,7 @@ bfd_get_arch_size (bfd *abfd)
>    if (abfd->xvec->flavour == bfd_target_elf_flavour)
>      return get_elf_backend_data (abfd)->s->arch_size;
>  
> -  return -1;
> +  return bfd_arch_bits_per_address (abfd);

This might be better:
  return bfd_arch_bits_per_address (abfd) > 32 ? 64 : 32;

On more than one target, bfd_arch_bits_per_address will return 16,
and more than one target returns 24.  So your patch would mean you
need to change the test in objdump.c, and you'd break
nm.c:set_print_width.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [Patch]: Fix bfd_get_arch_size for non-ELF targets

[Tristan Gingold]

On 03 Apr 2014, at 14:34, Alan Modra <amodra@gmail.com> wrote:

> On Thu, Apr 03, 2014 at 12:09:04PM +0200, Tristan Gingold wrote:
>> --- a/bfd/bfd.c
>> +++ b/bfd/bfd.c
>> @@ -1087,7 +1087,7 @@ bfd_get_arch_size (bfd *abfd)
>>   if (abfd->xvec->flavour == bfd_target_elf_flavour)
>>     return get_elf_backend_data (abfd)->s->arch_size;
>> 
>> -  return -1;
>> +  return bfd_arch_bits_per_address (abfd);
> 
> This might be better:
>  return bfd_arch_bits_per_address (abfd) > 32 ? 64 : 32;
> 
> On more than one target, bfd_arch_bits_per_address will return 16,
> and more than one target returns 24.  So your patch would mean you
> need to change the test in objdump.c, and you'd break
> nm.c:set_print_width.

You're right.  I have also adjusted the spec of that function.

Is that ok ?

Tristan.

bfd/
	* bfd.c (bfd_get_arch_size): Default is taken from arch.


diff --git a/bfd/bfd.c b/bfd/bfd.c
index 6b00592..41de1bb 100644
--- a/bfd/bfd.c
+++ b/bfd/bfd.c
@@ -1073,9 +1073,11 @@ SYNOPSIS
  	int bfd_get_arch_size (bfd *abfd);
 
 DESCRIPTION
-	Returns the architecture address size, in bits, as determined
-	by the object file's format.  For ELF, this information is
-	included in the header.
+	Returns the normalized architecture address size, in bits, as
+	determined by the object file's format.  By normalized, we mean
+	either 32 or 64.  For ELF, this information is included in the
+	header.  Use bfd_arch_bits_per_address for number of bits in
+	the architecture address.
 
 RETURNS
 	Returns the arch size in bits if known, <<-1>> otherwise.
@@ -1087,7 +1089,7 @@ bfd_get_arch_size (bfd *abfd)
   if (abfd->xvec->flavour == bfd_target_elf_flavour)
     return get_elf_backend_data (abfd)->s->arch_size;
 
-  return -1;
+  return bfd_arch_bits_per_address (abfd) > 32 ? 64 : 32;
 }
 
 /*

Re: [Patch]: Fix bfd_get_arch_size for non-ELF targets

[Alan Modra]

On Thu, Apr 03, 2014 at 02:48:35PM +0200, Tristan Gingold wrote:
> 	* bfd.c (bfd_get_arch_size): Default is taken from arch.

OK.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [Patch]: Fix bfd_get_arch_size for non-ELF targets

[Tristan Gingold]

On 04 Apr 2014, at 01:16, Alan Modra <amodra@gmail.com> wrote:

> On Thu, Apr 03, 2014 at 02:48:35PM +0200, Tristan Gingold wrote:
>> 	* bfd.c (bfd_get_arch_size): Default is taken from arch.
> 
> OK.

Thanks, now pushed.

Tristan.