Re: known-elf.awk/known-elf.h

[Mark Wielaard <mjw at redhat dot com>]

On Tue, Mar 24, 2015 at 01:47:39PM +0100, Petr Machata wrote:
> dwgrep needs to programmatically work with ELF constants, so I put
> together the attached script.
> 
> The basic idea is the same as with known-dwarf, but elf.h has some extra
> challenges to address:
> 
> - It's not entirely predictable which constants are bona fide values,
>   and which are metavalues that e.g. count numbers of other constants,
>   or e.g. flags.  The script handles this by having a whitelist of
>   constant types to admit, and then some heuristics to remove the
>   non-values.

So we have to be careful when importing new elf.h versions and double
check the known-elf.h differences.
 
> - Arch- and OS-specific values are rather the norm in ELF.  I didn't
>   find any collisions in per-OS ranges, but plenty of them in per-PROC
>   ranges, so the latter is actually addressed in the generated headers.
>   The following example illustrates how the facility is used.
> 
>     /* Per-constant executor.  */
>     #define ELF_ONE_KNOWN_STB(SHORT, LONG) /* ... */
> 
>       /* Visit generic constants.  */
>       ELF_ALL_KNOWN_STB
> 
>     /* STB_ per-arch executor.  */
>     #define ELF_ONE_KNOWN_STB_ARCH(ARCH)          \
>               /* ... */                           \
>               /* Visit STB_ARCH_* constants.  */  \
>               ELF_ALL_KNOWN_STB_##ARCH            \
>               /* ... */
> 
>       /* Visit arches known for STB_ constants.  */
>       ELF_ALL_KNOWN_STB_ARCHES
> 
>     #undef ELF_ONE_KNOWN_STB_ARCH
>     #undef ELF_ONE_KNOWN_STB

And you can match against EM_##ARCH in the per-arch executor to select
the correct one for the ELF you are examining?

> I'm attaching the script as well as the generated .h for preliminary
> assesment.  Let me know if you think this would be a good addition to
> elfutils, and any comments that you might have.  If this seems
> acceptable, I'll send a full-fledged patch.

I do like the idea. But there is one extra issue if we want this to be
an installed header like known-dwarf.h now is (and I think we do).
It is generated against libelf/elf.h which is our local copy of elf.h
from glibc. We do that to make sure we have the latest version with
all relevant constants. But that means it might be different from the
version of elf.h on the installed system. So to make it useful we
also need to install our elf.h as elfutils/elf.h. I think that is fine
but it is also a little weird since it really is glibc's elf.h.

Cheers,

Mark