Hi,
On 15/03/18 13:00, Laurent Vivier wrote:
> Le 15/03/2018 à 11:52, James Cowgill a écrit :
>> Hi,
>>
>> On 14/03/18 16:13, Laurent Vivier wrote:
>>> Le 14/03/2018 à 16:31, James Cowgill a écrit :
>>>> +enum {
>>>> + HWCAP_MIPS_R6 = (1 << 0),
>>>> + HWCAP_MIPS_MSA = (1 << 1),
>>>> +};
>>>
>>> We have this for ARM only in elfload.c since:
>>>
>>> afce2927aa Arm AT_HWCAP AUXV entry (Paul Brook) [2005]
>>>
>>> but they have been added in include/elf.h since:
>>>
>>> 41d9ea80ac tcg-arm: Use qemu_getauxval [Richard Henderson, 2013]
>>>
>>> and I think we should remove them (they are prefixed by ARM_)
>>>
>>> So the MIPS ones should be in include/elf.h (with the #define form).
>>
>> I can do that, although I think it's a bit unusual. The HWCAP bits are
>> specific to the Linux kernel and not to "the MIPS ELF format" so it
>> doesn't make sense to me to put them in elf.h.
>
> In fact, in a system, they come with the glibc <sys/auxv.h>. auxv.h
> includes <elf.h> and <bits/hwcap.h>. They are both part of glibc.
None of the headers you mention contain hwcap bits. They are usually
provided in an arch specific kernel header - on MIPS they are in
<asm/hwcap.h> which must be included separately.
> They can be used with qemu_getauxval() so it's better to have them in a
> header file. elfoad.c or elf.h, it's in both cases an ELF file.
I agree with that.
I tried to move them to elf.h but hit a slight problem. In elfload.c,
elf.h is included after all the target specific stuff so the
get_elf_hwcap function cannot use anything from elf.h. I think this has
lead to all architectures replicating the list of hwcap bits in both
elf.h and elfload.c. You mentioned arm before, but I can also see
aarch64, powerpc and sh4 do this. Some of these architectures also have
their bits (with different constant names) in elf.h and some do not.
James
