Re: [Elftoolchain-developers] libelf and linux objtool

[Joseph K. <jk...@us...>]

On Sun, Jun 09, 2019 at 02:25:38AM -0700, Michael Forney wrote:

m.f> 1. objtool defines its own elf_open function, used

The elf(3) manual page lists the symbol prefixes in use by
the library.

m.f> It looks like this is because the elftoolchain
m.f> ELF64_R_INFO macro shifts its first argument by 32,
m.f> but objtool passes an unsigned int, so the value was
m.f> getting lost. I resolved this with the diff below.

Applied in r3742, thanks!

m.f> 3. I also noticed that when elf_update recomputes
m.f> the section layout, it leaves the section offset
m.f> of SHT_NOBITS and SHT_NULL sections alone while
m.f> the others are updated. elfutils sets the offset
m.f> of the section based on the ending of the previous
m.f> section. Does this offset have any meaning, or
m.f> is it just arbitrary? Either way, maybe it makes
m.f> sense to set it to the end of the previous section
m.f> to avoid inheriting the value from the original
m.f> section layout.

Would you have a short example program that shows
the difference in behavior of elfutils' libelf and
elftoolchain's libelf?

Per my understanding, for a section of type SHT_NULL,
the rest of the fields in the section header are
undefined.  For a section of type SHT_NOBITS,
the offset and size fields are defined to be a
'conceptual' offset and size of the section; these
values would be set by the application that adds a
SHT_NOBITS section to the object.

When libelf is told to lay out an ELF object (i.e.,
when the ELF_F_LAYOUT flag is not set on the Elf
descriptor), then it isn't clear what the fields of a
SHT_NOBITS section header would need to be set to.

m.f> 4. This is a bit unrelated to objtool,
m.f> but I noticed that elfdefinitions.h contains
m.f> several enums with values that are too big for
m.f> int (specifically, EF_PPC_EMB, SHF_COMDEF,
m.f> SHF_MIPS_STRING, SHF_EXCLUDE, SHF_MASKPROC,
m.f> SHT_LOUSER, and SHT_HIUSER). The C standard says
m.f> that all enumerator values must be representable as
m.f> int, and have type int. Maybe it makes sense to use
m.f> preprocessor defines for these instead? In addition
m.f> to fixing ISO C conformance, this would also ensure
m.f> that the enumerators have a consistent signedness
m.f> (gcc will choose int for those less than 2^31,
m.f> and unsigned for those that are greater or equal).

I generally prefer using enumerations to preprocessor
symbols.

As far as ISO C conformance goes, casting the literals
defining these symbols to 'int' might suffice, since
none of these values would need more than 32 bits
for their representation; I will take a look.

Regards,
Joseph Koshy