Currently, Pro64 only output .s files. It does not generate elf object
at all. If you want elf object, then you have to do something to make
that happen. The compiler used to generate elf object directly, but
has been changed to conform to gcc's convention. I doubt if direct
object generation works anymore.
One needs to be careful with -IPA though. The IR from IPA phase is
disguised as ELF objects. If you don't care about IPA, you don't need
to worry about it. Otherwise, you just have to define your own 32 bit
format (that should be a no brainer, the compiler used to produce both
64bit and 32 bit code under a switch) so that IPA can put it out and
read it back properly. I believe the code is done in the so call "gatherer".
I.e. first phase of a traditional linker.
Sun
> -----Original Message-----
> From: Benedict R. Gaster [mailto:benedict.gaster@xxxxxx]
> Sent: Tuesday, June 12, 2001 3:33 AM
> To: Pro64 Contrib
> Subject: ELF binaries when only wishing to produce assembler code...
>
>
> Hello!
>
> I am currently involved in looking at the process of porting
> the Pro64 to
> new 32bit architecture and have some difficulty in completly
> understanding
> the ELF requirements. The problem is that we are only interested in
> producing assembler suitable for input into a version of GAS
> and not with
> producing object modules directly. However, it is by no means
> clear if a
> Pro64 compiler can be built to target the assembler only.
>
> There are a number of header files releated to ELF:
>
> ./common/com/config_elf_targ.h --- prototypes API for
> target/machine ELF
> configuration.
> ./common/com/em_elf.h --- prototypes API for
> writing ELF module.
>
> Corresponding C++ source files are provided in:
>
> ./common/com/ia64/config_elf_targ.cxx
> ./common/com/ia64/targ_em_elf.cxx
>
> which provide, ia64, implementations of the specified ELF
> APIs. These two
> files files, along with an additional header also defined in
> common/com/ia64, are straightforward to implement for a new
> architecture.
>
> The following header defines some C++ typedefs used to
> instantiate templates
> that are based on the format of an Elf object and requires no porting:
>
> ./common/com/ir_elf.h
>
> ./include/cmplrs/elf_interfaces.h --- provides a consumer API to the
> .MIPS.interfaces ELF section
> ./include/elf_abi.h --- defines one additional
> hash define on
> top of <elf.h>
> ./include/elf_mips.h --- not sure what this is
> used for other
> than the cygnus_20000828/bfd
> ./include/elfaccess.h --- provides access macros for the ELF
> structures.
>
> The following header defines a number of special, MIPS, ELF
> sections for
> WHIRL, which, although the hash defines all make reference to
> MIPS, does not
> seem to require any modification:
>
> ./include/sys/elf_whirl.h
>
> The following header specifies sections and relocations for
> the Irix/ia64
> and additional Intel ia64:
>
> ./include/sys/ia64/elf.h --- specify sections, relocations
> for Irix/ia64 and
> Intel specific
>
> It is clear that if we are to produce ELF object modules
> compatable with a
> version of ld, then this file must be ported to detail the required
> definitions.
>
> A number of the hash defines used in the above headers appear
> in the more
> generic header:
>
> ./linux/include/elf.h
>
> In particular, *_IRIX_* definitons. Currently this file does
> not contain
> definitions for our architecture, although we do have an ELF
> number and so
> on, and it is not clear how much work it would be ammend this file as
> required.
>
> ./ipa/local/ipl_elfsym.h --- convert WHIRL global symbol
> table to Elf.
>
> plus a number that appear under the GCC and G++ front-ends,
> which do not
> seem important to this discussion as they are used to produce
> parse trees
> and not RTL, etc.
>
> So with the ELF references mapped out is it possible to build
> the Pro64
> compiler to produce only assembler?
>
> thanks for any advice on this matter.
>
> ben.
>
>
|