This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Kazuhiro, > I am preparing porting of m32r-linux target GNU tools. > > At the first, I think that it needs new relocations (R_M32R_GOT24, > R_M32R_26_PLTREL, R_M32R_GOT24 .. .etc). Now we have only m32r-elf > target. Would you tell me the process of porting new targets if > there are any policies? Important things to bare in mind when creating a new port: * Make sure that it doe snot break other ports. In particular check that native toolchains still build/work correctly after your changes. * Make sure that a toolchain configured with --enable-targets=all --enable-64-bit-bfd will build and run. * Ideally the m32r-linux port should be compatible with the m32r-elf port. If this is not possible, (eg because of ABI differences) then you must make sure that you have a way to distinguish binary files from the two ports. Typical methods used by other toolchains include bits in the e_flags[] field of the ELF header and a special .note section. > Do we need to keep the compatibility of m32r-linux relocations with > m32r-elf? I want to change relocation type form REL to RELA for > porting linux form now. It is possible to support both REL and RELA relocs in the same target, although it can be complicated. One method would be to create a new set of relocs which map onto the current set, but which are their RELA equivalents. (eg R_M32R_16_RELA would be the RELA equivalent of R_M32R_16). You could code the linker so that it would be able to handle both sets of reloc numbers and so retain compatibility with the current m32r-elf files. Cheers Nick
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |