Hi Ramana,
+/* Get the definitions of the ARM EABI Attribute tag values. */
+#define BFD_ARCH_SIZE
+#include "elf/arm.h"
Defining BFD_ARCH_SIZE appears to be a bit of a hack. I would also
ifdef this inclusion on TARGET_AAPCS since we shouldn't really be
caring about object attributes for non AAPCS configurations.
Hmm, there does not appear to be any compile-time define that I can
reliably use for this.
Does elf/arm.h get installed by bfd / binutils in some form as a part
of it's build process ? Can the compiler find elf/arm.h by default for
a non-combined-tree arm-linux-gnueabi / arm-eabi cross-build or a
native boostrap ?
Err, probably not. I forgot that the elf/ subdirectory of the include/
directory is not shared between gcc and binutils.
Instead may I suggest rejigging this in a form so that we share this
header file between gcc and binutils and make sure that this is
sufficiently documented that one master copy lives in one repository
while the other is a copy of this is in the other repository ?
This would be a good idea.
It
has the same problems that we have with sharing other files between
these 2 repositories but causing pain to every single script out there
to add an include path to a default build sounds wrong to me.
Agreed.
I think that there are two possible ways to go:
1. Create a new file include/arm-eabi-attrs.h to be shared between gcc
and binutils and alter include/elf/arm.h to use this file. The problem
with this idea is that it adds a target specific file to the include/
directory, which really should be target agnostic. (I know that there
are some xtensa header files there, but IMHO that was a mistake).
2. Abandon using a header file at all. Instead use a configure test
to see if we are using an assembler that supports textual names in a
.eabi_attribute directive and if so use the names rather than the numbers.
Any preference ?
Cheers
Nick
