H8 targets.

H8 targets.

[Nitin Gupta, Noida]

Hi,
	The elf.h contains the follwoing different e_machine value for
different
	H8 architectures:

	#define EM_H8_300        46              /* Hitachi H8/300 */
	#define EM_H8_300H      47              /* Hitachi H8/300H */
	#define EM_H8S             48              /* Hitachi H8S */

	Then why is it that H8300-elf uses e_machine = EM_H8_300 
	for all  <default> , -ms , -mh targets?  To differentiate between
targets, 
	it uses Processor specific flags (e_flags) instead. 
	Due to these the utilities like "file" does not identify the
architecture
	correctly. Though h8300-elf-readelf does it.

Thanks and Regards.
Nitin.

Re: H8 targets.

[Nick Clifton]

Hi Nitin,

> The elf.h contains the follwoing different e_machine value for
> different H8 architectures:

You mean include/elf/common.h, but anyway...

> Then why is it that H8300-elf uses e_machine = EM_H8_300 
> for all  <default> , -ms , -mh targets?  To differentiate between
> targets, it uses Processor specific flags (e_flags) instead.

There is no comment in the code to explain this discrepancy.  It may
be that these numbers were allocated after the code in the BFD library
was written, and so they were not known to the author.  Or it may be
that the ABI for the h8300x series specifies that the e_flags field
should be used.  Or it may well be a bug in the h8300 code in the BFD
library.

I suspect however that the reason is that in order to able to support
producing h8300, h8300s and h8300h binaries from the just one toolchain
(instead of three separate ones) the author chose to select a single
machine number and then use the flags to distinguish the different
processor varieties.  (This is the standard behavior for other ELF
based toolchains).


> Due to these the utilities like "file" does not identify the
> architecture correctly. Though h8300-elf-readelf does it.

Is this a serious problem ?

Cheers
        Nick

Re: H8 targets.

[Hans-Peter Nilsson]

On 15 Jul 2002, Nick Clifton wrote:
> > The elf.h contains the follwoing different e_machine value for
> > different H8 architectures:
>
> You mean include/elf/common.h, but anyway...
>
> > Then why is it that H8300-elf uses e_machine = EM_H8_300
> > for all  <default> , -ms , -mh targets?  To differentiate between
> > targets, it uses Processor specific flags (e_flags) instead.

> > Due to these the utilities like "file" does not identify the
> > architecture correctly. Though h8300-elf-readelf does it.
>
> Is this a serious problem ?

Am I totally off here, or wouldn't adding
 #define ELF_MACHINE_ALT1 EM_H8_300H
 #define ELF_MACHINE_ALT2 EM_H8S
to elf32-h8300.c help recognizing those files presumably created
by other toolchains?

brgds, H-P

Re: H8 targets.

[Nick Clifton]

Hi Hans-Peter,

> > > Due to these the utilities like "file" does not identify the
> > > architecture correctly. Though h8300-elf-readelf does it.
> >
> > Is this a serious problem ?
> 
> Am I totally off here, or wouldn't adding
>  #define ELF_MACHINE_ALT1 EM_H8_300H
>  #define ELF_MACHINE_ALT2 EM_H8S
> to elf32-h8300.c help recognizing those files presumably created
> by other toolchains?

Yup I expect so.  I was just being lazy! :-)

Nitin - would you like to try that out and let us know if it works for
you ?

Cheers
        Nick

Re: H8 targets.

[Jeff Law]

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

In message <m3d6tpw0t1.fsf@north-pole.nickc.cambridge.redhat.com>, Nick Clifton
 writes:
 >Hi Nitin,
 >
 >> The elf.h contains the follwoing different e_machine value for
 >> different H8 architectures:
 >
 >You mean include/elf/common.h, but anyway...
 >
 >> Then why is it that H8300-elf uses e_machine = EM_H8_300 
 >> for all  <default> , -ms , -mh targets?  To differentiate between
 >> targets, it uses Processor specific flags (e_flags) instead.
 >
 >There is no comment in the code to explain this discrepancy.  It may
 >be that these numbers were allocated after the code in the BFD library
 >was written, and so they were not known to the author.  Or it may be
 >that the ABI for the h8300x series specifies that the e_flags field
 >should be used.  Or it may well be a bug in the h8300 code in the BFD
 >library.
I believe this is my fault.  I wasn't aware of the existing spec
which used different ELF_MACHINE values for the different H8 variants
so instead I used a scheme which encodes that information into the 
flags field in a manner similar to what is done for MIPS and other targets.

The only problem with changing things now is that you'll make the GNU
tools incompatible with previous releases of the GNU tools.  Then again,
it's probably still the right thing to do, but it'll need to be clearly
documented in the release notes for the binutils release where the change
becomes effective.

I've got these changes sitting in my local tree -- I haven't looked at them
in any detail in nearly a year, but they may be useful to anyone trying to
fix this little problem.



jeff

[-- Attachment #2: P --]
[-- Type: text/plain , Size: 5293 bytes --]

Index: elf32-h8300.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-h8300.c,v
retrieving revision 1.15
diff -c -3 -p -r1.15 elf32-h8300.c
*** elf32-h8300.c	23 Jul 2002 12:29:32 -0000	1.15
--- elf32-h8300.c	12 Aug 2002 17:35:57 -0000
*************** static void elf32_h8_info_to_howto
*** 30,37 ****
    PARAMS ((bfd *, arelent *, Elf_Internal_Rela *));
  static void elf32_h8_info_to_howto_rel
    PARAMS ((bfd *, arelent *, Elf32_Internal_Rel *));
! static unsigned long elf32_h8_mach
!   PARAMS ((flagword));
  static void elf32_h8_final_write_processing
    PARAMS ((bfd *, boolean));
  static boolean elf32_h8_object_p
--- 30,45 ----
    PARAMS ((bfd *, arelent *, Elf_Internal_Rela *));
  static void elf32_h8_info_to_howto_rel
    PARAMS ((bfd *, arelent *, Elf32_Internal_Rel *));
! static bfd_reloc_status_type special 
!   PARAMS ((bfd *, arelent *, asymbol *, PTR, asection *, bfd *, char **));
! static bfd_reloc_status_type elf32_h8_final_link_relocate
!   PARAMS ((unsigned long, bfd *, bfd *, asection *,
! 	   bfd_byte *, bfd_vma, bfd_vma, bfd_vma,
! 	   struct bfd_link_info *, asection *, int));
! static boolean elf32_h8_relocate_section
!   PARAMS ((bfd *, struct bfd_link_info *, bfd *, asection *,
! 	   bfd_byte *, Elf_Internal_Rela *,
! 	   Elf_Internal_Sym *, asection **));
  static void elf32_h8_final_write_processing
    PARAMS ((bfd *, boolean));
  static boolean elf32_h8_object_p
*************** static boolean elf32_h8_symbol_address_p
*** 47,62 ****
  static bfd_byte *elf32_h8_get_relocated_section_contents
    PARAMS ((bfd *, struct bfd_link_info *, struct bfd_link_order *,
  	   bfd_byte *, boolean, asymbol **));
- static bfd_reloc_status_type elf32_h8_final_link_relocate
-   PARAMS ((unsigned long, bfd *, bfd *, asection *,
- 	   bfd_byte *, bfd_vma, bfd_vma, bfd_vma,
- 	   struct bfd_link_info *, asection *, int));
- static boolean elf32_h8_relocate_section
-   PARAMS ((bfd *, struct bfd_link_info *, bfd *, asection *,
- 	   bfd_byte *, Elf_Internal_Rela *,
- 	   Elf_Internal_Sym *, asection **));
- static bfd_reloc_status_type special
-   PARAMS ((bfd *, arelent *, asymbol *, PTR, asection *, bfd *, char **));
  
  /* This does not include any relocation information, but should be
     good enough for GDB or objdump to read the file.  */
--- 55,60 ----
*************** elf32_h8_relocate_section (output_bfd, i
*** 556,584 ****
    return true;
  }
  
- /* Object files encode the specific H8 model they were compiled
-    for in the ELF flags field.
- 
-    Examine that field and return the proper BFD machine type for
-    the object file.  */
- static unsigned long
- elf32_h8_mach (flags)
-      flagword flags;
- {
-   switch (flags & EF_H8_MACH)
-     {
-     case E_H8_MACH_H8300:
-     default:
-       return bfd_mach_h8300;
- 
-     case E_H8_MACH_H8300H:
-       return bfd_mach_h8300h;
- 
-     case E_H8_MACH_H8300S:
-       return bfd_mach_h8300s;
-     }
- }
- 
  /* The final processing done just before writing out a H8 ELF object
     file.  We use this opportunity to encode the BFD machine type
     into the flags field in the object file.  */
--- 554,559 ----
*************** elf32_h8_final_write_processing (abfd, l
*** 594,613 ****
      {
      default:
      case bfd_mach_h8300:
!       val = E_H8_MACH_H8300;
        break;
  
      case bfd_mach_h8300h:
!       val = E_H8_MACH_H8300H;
        break;
  
      case bfd_mach_h8300s:
!       val = E_H8_MACH_H8300S;
        break;
      }
  
!   elf_elfheader (abfd)->e_flags &= ~ (EF_H8_MACH);
!   elf_elfheader (abfd)->e_flags |= val;
  }
  
  /* Return nonzero if ABFD represents a valid H8 ELF object file; also
--- 569,587 ----
      {
      default:
      case bfd_mach_h8300:
!       val = EM_H8_300;
        break;
  
      case bfd_mach_h8300h:
!       val = EM_H8_300H;
        break;
  
      case bfd_mach_h8300s:
!       val = EM_H8S;
        break;
      }
  
!    elf_elfheader (abfd)->e_machine = val;
  }
  
  /* Return nonzero if ABFD represents a valid H8 ELF object file; also
*************** static boolean
*** 617,624 ****
  elf32_h8_object_p (abfd)
       bfd *abfd;
  {
!   bfd_default_set_arch_mach (abfd, bfd_arch_h8300,
! 			     elf32_h8_mach (elf_elfheader (abfd)->e_flags));
    return true;
  }
  
--- 591,613 ----
  elf32_h8_object_p (abfd)
       bfd *abfd;
  {
!   switch (elf_elfheader(abfd)->e_machine)
!     {
!       case EM_H8_300:
!         bfd_default_set_arch_mach (abfd, bfd_arch_h8300,
! 				   bfd_mach_h8300);
! 	break;
!       case EM_H8_300H:
!         bfd_default_set_arch_mach (abfd, bfd_arch_h8300,
! 				   bfd_mach_h8300h);
! 	break;
!       case EM_H8S:
!         bfd_default_set_arch_mach (abfd, bfd_arch_h8300,
! 				   bfd_mach_h8300s);
! 	break;
!       default:
! 	return false;
!     }
    return true;
  }
  
*************** elf32_h8_get_relocated_section_contents 
*** 1425,1430 ****
--- 1414,1421 ----
  #define TARGET_BIG_NAME			"elf32-h8300"
  #define ELF_ARCH			bfd_arch_h8300
  #define ELF_MACHINE_CODE		EM_H8_300
+ #define ELF_MACHINE_ALT1		EM_H8_300H
+ #define ELF_MACHINE_ALT2		EM_H8S
  #define ELF_MAXPAGESIZE			0x1
  #define bfd_elf32_bfd_reloc_type_lookup elf32_h8_reloc_type_lookup
  #define elf_info_to_howto		elf32_h8_info_to_howto

RE: H8 targets.

[Nitin Gupta, Noida]

 >> The only problem with changing things now is that you'll 
> make the GNU
>  >> tools incompatible with previous releases of the GNU tools.  
>  >> Then again,
>  >> it's probably still the right thing to do, but it'll need to 
>  >> be clearly
>  >> documented in the release notes for the binutils release 
>  >> where the change
>  >> becomes effective.
>  >> 
>  >> I've got these changes sitting in my local tree -- I haven't 
>  >> looked at them
>  >> in any detail in nearly a year, but they may be useful to 
>  >> anyone trying to
>  >> fix this little problem.
>  >> 
>  >
>  >Without this patch the third party debuggers (e.g. HDI) 
>  >may fail to recognize the binary generated by h8300-elf-gcc.
>  >The patch is running fine for me. After applying the same
>  >patch to gdb, the h8300-elf-run also executes the binaries
>  >gracefully.
> Yes, but with the patch the GNU tools won't be able to 
> interoperate with
> objects built by earlier releases of the tools.
> 
> I wonder if we could actually use both schemes and keep compatibility
> with both 3rd party tools as well as earlier versions of the 
> GNU tools.
> 
> 
> First we look at the ELF_MACHINE bits.  If it's EM_H8_300H or 
> EM_H8S, then
> we're done.  If the machien id is EM_H8_300, then we peek at 
> the flags bits.
> If the flag bugs are set, then we use them to set the machine 
> type, if the
> flag bits are not set, then we're plain H8/300.
> 
The H8300 third party tool chain (supplied with HEW) 
make use of value 0x0, 0x1, 0x2, 0x3 and 0x4 of e_flag 
field for address space width = default(=16), 20 , 24,
28 and 32 respectively. Since there is no conflict
with the e_flag values used by binutils for H8300 targets,
the tools may continue to support old combination
of e_machine and e_flag also. However the latest 
binutils  may generate the elf binary with the 
e_machine and e_flag value that is compatible
with HEW tool chain only.

Since GCC support byte addressing only hence in case 
of H8S and H8300H targets the value of e_flags may be 
set to 0x4 and for H8300 target value 0x0 may be 
retained as e_flags.

Please let me know your opinion about this.

Thanks and Regards,
Nitin.

Re: H8 targets.

[Jeff Law]

In message <E04CF3F88ACBD5119EFE00508BBB2121042BF27B@exch-01.noida.hcltech.com>
, "Nitin Gupta, Noida" writes:
 >Thanks a lot for your patch.
 >
 >> 
 >> The only problem with changing things now is that you'll make the GNU
 >> tools incompatible with previous releases of the GNU tools.  
 >> Then again,
 >> it's probably still the right thing to do, but it'll need to 
 >> be clearly
 >> documented in the release notes for the binutils release 
 >> where the change
 >> becomes effective.
 >> 
 >> I've got these changes sitting in my local tree -- I haven't 
 >> looked at them
 >> in any detail in nearly a year, but they may be useful to 
 >> anyone trying to
 >> fix this little problem.
 >> 
 >
 >Without this patch the third party debuggers (e.g. HDI) 
 >may fail to recognize the binary generated by h8300-elf-gcc.
 >The patch is running fine for me. After applying the same
 >patch to gdb, the h8300-elf-run also executes the binaries
 >gracefully.
Yes, but with the patch the GNU tools won't be able to interoperate with
objects built by earlier releases of the tools.

I wonder if we could actually use both schemes and keep compatibility
with both 3rd party tools as well as earlier versions of the GNU tools.


First we look at the ELF_MACHINE bits.  If it's EM_H8_300H or EM_H8S, then
we're done.  If the machien id is EM_H8_300, then we peek at the flags bits.
If the flag bugs are set, then we use them to set the machine type, if the
flag bits are not set, then we're plain H8/300.

Thoughts?

jeff

RE: H8 targets.

[Nitin Gupta, Noida]

Thanks a lot for your patch.

> 
> The only problem with changing things now is that you'll make the GNU
> tools incompatible with previous releases of the GNU tools.  
> Then again,
> it's probably still the right thing to do, but it'll need to 
> be clearly
> documented in the release notes for the binutils release 
> where the change
> becomes effective.
> 
> I've got these changes sitting in my local tree -- I haven't 
> looked at them
> in any detail in nearly a year, but they may be useful to 
> anyone trying to
> fix this little problem.
> 

Without this patch the third party debuggers (e.g. HDI) 
may fail to recognize the binary generated by h8300-elf-gcc.
The patch is running fine for me. After applying the same
patch to gdb, the h8300-elf-run also executes the binaries
gracefully.

Thanks and Regards,
Nitin.