Re: [Elftoolchain-developers] libelf and linux objtool

[Michael F. <mf...@mf...>]

Thanks for your response.

On 2019-06-09, Joseph Koshy <jk...@us...> wrote:
> On Sun, Jun 09, 2019 at 02:25:38AM -0700, Michael Forney wrote:
> 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.

I might be able to come up with an example later, but hopefully the
attached shell session explains the difference I'm seeing.

> 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.

Yes, generally I agree, but unfortunately the standard limits the
values to the range of int, so they aren't suitable for some purposes.

> 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.

Converting a value greater than INT_MAX to int is implementation
defined, but perhaps it would work as intended for all implementations
you care about. I also wonder if there are any cases where these large
constants are shifted right. If they were cast to int, the sign
extension could cause problems.