Message ID | 20180423075215.4572-3-christophe.lyon@st.com |
---|---|
State | Superseded |
Headers | show |
Series | FDPIC ABI for ARM | expand |
On 23 April 2018 at 08:51, Christophe Lyon <christophe.lyon@st.com> wrote: > Define an ARM-specific version of elf_is_fdpic: > FDPIC ELF objects are identified with e_ident[EI_OSABI] == > ELFOSABI_ARM_FDPIC. > > Co-Authored-By: Mickaël Guêné <mickael.guene@st.com> > Signed-off-by: Christophe Lyon <christophe.lyon@st.com> > > diff --git a/include/elf.h b/include/elf.h > index c0dc9bb..934dbbd 100644 > --- a/include/elf.h > +++ b/include/elf.h > @@ -1483,6 +1483,7 @@ typedef struct elf64_shdr { > #define ELFOSABI_TRU64 10 /* Compaq TRU64 UNIX. */ > #define ELFOSABI_MODESTO 11 /* Novell Modesto. */ > #define ELFOSABI_OPENBSD 12 /* OpenBSD. */ > +#define ELFOSABI_ARM_FDPIC 65 /* ARM FDPIC */ > #define ELFOSABI_ARM 97 /* ARM */ > #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */ > > diff --git a/linux-user/elfload.c b/linux-user/elfload.c > index bbe93b0..76d7718 100644 > --- a/linux-user/elfload.c > +++ b/linux-user/elfload.c > @@ -1681,11 +1681,18 @@ static void zero_bss(abi_ulong elf_bss, abi_ulong last_bss, int prot) > } > } > > +#ifdef TARGET_ARM > +static int elf_is_fdpic(struct elfhdr *exec) > +{ > + return exec->e_ident[EI_OSABI] == ELFOSABI_ARM_FDPIC; > +} > +#else > /* Default implementation, always false. */ > static int elf_is_fdpic(struct elfhdr *exec) > { > return 0; > } > +#endif I have a strong dislike for per-target ifdef ladders. Can we instead put the target's implementation of elf_is_fdpic() into linux-user/$ARCH/target_elf.h and also have that header do #define TARGET_HAS_ELF_FDPIC and then in the generic code we can protect the default elf_is_fdpic() with #ifndef TARGET_HAS_ELF_FDPIC. thanks -- PMM
On 23/04/2018 14:17, Peter Maydell wrote: > On 23 April 2018 at 08:51, Christophe Lyon <christophe.lyon@st.com> wrote: >> Define an ARM-specific version of elf_is_fdpic: >> FDPIC ELF objects are identified with e_ident[EI_OSABI] == >> ELFOSABI_ARM_FDPIC. >> >> Co-Authored-By: Mickaël Guêné <mickael.guene@st.com> >> Signed-off-by: Christophe Lyon <christophe.lyon@st.com> >> >> diff --git a/include/elf.h b/include/elf.h >> index c0dc9bb..934dbbd 100644 >> --- a/include/elf.h >> +++ b/include/elf.h >> @@ -1483,6 +1483,7 @@ typedef struct elf64_shdr { >> #define ELFOSABI_TRU64 10 /* Compaq TRU64 UNIX. */ >> #define ELFOSABI_MODESTO 11 /* Novell Modesto. */ >> #define ELFOSABI_OPENBSD 12 /* OpenBSD. */ >> +#define ELFOSABI_ARM_FDPIC 65 /* ARM FDPIC */ >> #define ELFOSABI_ARM 97 /* ARM */ >> #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */ >> >> diff --git a/linux-user/elfload.c b/linux-user/elfload.c >> index bbe93b0..76d7718 100644 >> --- a/linux-user/elfload.c >> +++ b/linux-user/elfload.c >> @@ -1681,11 +1681,18 @@ static void zero_bss(abi_ulong elf_bss, abi_ulong last_bss, int prot) >> } >> } >> >> +#ifdef TARGET_ARM >> +static int elf_is_fdpic(struct elfhdr *exec) >> +{ >> + return exec->e_ident[EI_OSABI] == ELFOSABI_ARM_FDPIC; >> +} >> +#else >> /* Default implementation, always false. */ >> static int elf_is_fdpic(struct elfhdr *exec) >> { >> return 0; >> } >> +#endif > > I have a strong dislike for per-target ifdef ladders. Can we instead > put the target's implementation of elf_is_fdpic() into > linux-user/$ARCH/target_elf.h > and also have that header do > #define TARGET_HAS_ELF_FDPIC > > and then in the generic code we can protect the default elf_is_fdpic() > with #ifndef TARGET_HAS_ELF_FDPIC. > How invasive could that be? Your proposal is appealing, but target_elf.h is only included by linux-user/main.c, which does not define elfhdr etc... All that knowledge is in linux-user/elfload.c, which controls what include/elf.h defines. Should I re-engineer that? Thanks, Christophe > thanks > -- PMM > . >
On 23 April 2018 at 13:53, Christophe Lyon <christophe.lyon@st.com> wrote: > On 23/04/2018 14:17, Peter Maydell wrote: >> I have a strong dislike for per-target ifdef ladders. Can we instead >> put the target's implementation of elf_is_fdpic() into >> linux-user/$ARCH/target_elf.h >> and also have that header do >> #define TARGET_HAS_ELF_FDPIC >> >> and then in the generic code we can protect the default elf_is_fdpic() >> with #ifndef TARGET_HAS_ELF_FDPIC. >> > > How invasive could that be? > Your proposal is appealing, but target_elf.h is only included by > linux-user/main.c, which does not define elfhdr etc... > All that knowledge is in linux-user/elfload.c, which controls what > include/elf.h defines. Hmm, I see what you mean. We can't even put the function inside the existing per-target ifdef ladder, because that comes before the include of elf.h halfway down elfload.c. That's a bit of a mess, but it's a mess we shouldn't try to clean up as part of this patchset, so Reviewed-by: Peter Maydell <peter.maydell@linaro.org> thanks -- PMM
diff --git a/include/elf.h b/include/elf.h index c0dc9bb..934dbbd 100644 --- a/include/elf.h +++ b/include/elf.h @@ -1483,6 +1483,7 @@ typedef struct elf64_shdr { #define ELFOSABI_TRU64 10 /* Compaq TRU64 UNIX. */ #define ELFOSABI_MODESTO 11 /* Novell Modesto. */ #define ELFOSABI_OPENBSD 12 /* OpenBSD. */ +#define ELFOSABI_ARM_FDPIC 65 /* ARM FDPIC */ #define ELFOSABI_ARM 97 /* ARM */ #define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */ diff --git a/linux-user/elfload.c b/linux-user/elfload.c index bbe93b0..76d7718 100644 --- a/linux-user/elfload.c +++ b/linux-user/elfload.c @@ -1681,11 +1681,18 @@ static void zero_bss(abi_ulong elf_bss, abi_ulong last_bss, int prot) } } +#ifdef TARGET_ARM +static int elf_is_fdpic(struct elfhdr *exec) +{ + return exec->e_ident[EI_OSABI] == ELFOSABI_ARM_FDPIC; +} +#else /* Default implementation, always false. */ static int elf_is_fdpic(struct elfhdr *exec) { return 0; } +#endif static abi_ulong loader_build_fdpic_loadmap(struct image_info *info, abi_ulong sp) {
Define an ARM-specific version of elf_is_fdpic: FDPIC ELF objects are identified with e_ident[EI_OSABI] == ELFOSABI_ARM_FDPIC. Co-Authored-By: Mickaël Guêné <mickael.guene@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@st.com> -- 2.6.3