On 8/7/21 11:42 AM, Warner Losh wrote:
> +++ b/bsd-user/x86_64/target_arch_elf.h
> @@ -19,48 +19,14 @@
> #ifndef_TARGET_ARCH_ELF_H_
> #define_TARGET_ARCH_ELF_H_
>
> -#define ELF_PLATFORM get_elf_platform()
> -
> -static const char *get_elf_platform(void)
> -{
> - static char elf_platform[] = "i386";
> - int family = object_property_get_int(OBJECT(thread_cpu), "family", NULL);
> - if (family > 6) {
> - family = 6;
> - }
> - if (family >= 3) {
> - elf_platform[1] = '0' + family;
> - }
> - return elf_platform;
> -}
> -
> -#define ELF_HWCAP get_elf_hwcap()
> -
> -static uint32_t get_elf_hwcap(void)
> -{
> - X86CPU *cpu = X86_CPU(thread_cpu);
> -
> - return cpu->env.features[FEAT_1_EDX];
> -}
> -
> #define ELF_START_MMAP 0x2aaaaab000ULL
> -#define elf_check_arch(x) (((x) == ELF_ARCH))
> +#define ELF_ET_DYN_LOAD_ADDR 0x01021000
> +#define elf_check_arch(x) ( ((x) == ELF_ARCH) )
This appears to be unrelated? Should this have been in a previous patch? Or is this a
rebase mistake that gets corrected later?
This turns out to be a very good question. It's exactly what I intended to do. It's a
copy of the latest development branch. However, digging into it shows that it is
none-the-less incorrect. It wasn't a mismerge, but it was code commented out 8
years ago which I removed in the merge. I had thought this meant it was unused.
In fact, it had been for some time. However, it's been wrong all that time and that
code should be restored not only here, but for other architectures I've not submitted.
It was unused, but not unneeded...
I'll trust the target_os_thread.h thing becomes useful later.
So, modulo the target_arch_elf.h weirdness,
Yes. It works well enough on x86, but since x86 isn't used by our project for more
than a basic sanity check, this breakage went unnoticed for some time...
I'll update with the next round. BTW, I've started to notice that many of the
items flagged by the style
commitcheck.pl script originated in the linux-user
code and it's still that way today... Do you have any advice for what I should
do about that, if anything?
Warner
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
r~