On Sun, Aug 8, 2021 at 3:43 PM Warner Losh <[email protected]> wrote: > > > On Sun, Aug 8, 2021 at 12:24 AM Richard Henderson < > [email protected]> wrote: > >> 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... >
Ah, it turns out this showed problems only in arm* and riscv on FreeBSD. The others publish HWCAP = 0 for some reason. And ELF_PLATFORM() is used in the most-recent bsd-user code. Some tweaks are needed, and I'll do those in V2 with the other style fixes. Warner > 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 <[email protected]> >> >> r~ >> >
