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 _______________________________________________ Elftoolchain-developers mailing list Elftoolchain-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/elftoolchain-developers
