On 24.09.2024 12:22, Frediano Ziglio wrote: > There are indeed some oddities in the final executable(s): > > From "objdump -x": > > xen/normal/xen.efi: file format pei-x86-64 > xen/normal/xen.efi > architecture: i386:x86-64, flags 0x0000013b: > HAS_RELOC, EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED > start address 0xffff82d04062bfdc > ... > The Data Directory > Entry 0 0000000000000000 00000000 Export Directory [.edata (or where > ever we found it)] > Entry 1 0000000000000000 00000000 Import Directory [parts of .idata] > Entry 2 0000000000000000 00000000 Resource Directory [.rsrc] > Entry 3 0000000000000000 00000000 Exception Directory [.pdata] > Entry 4 0000000000000000 00000000 Security Directory > Entry 5 00000000009489a0 000016c0 Base Relocation Directory [.reloc] > Entry 6 00000000004871c8 0000001c Debug Directory > Entry 7 0000000000000000 00000000 Description Directory > Entry 8 0000000000000000 00000000 Special Directory > ... > There is a debug directory in .buildid at 0xffff82d0404871c8 > ... > Sections: > Idx Name Size VMA LMA File off Algn > 0 .text 0018c5f6 ffff82d040200000 ffff82d040200000 00001000 2**4 > CONTENTS, ALLOC, LOAD, CODE > 1 .rodata 000871c8 ffff82d040400000 ffff82d040400000 0018e000 2**2 > CONTENTS, ALLOC, LOAD, DATA > 2 .buildid 00000035 ffff82d0404871c8 ffff82d0404871c8 002151e0 2**2 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .init.text 0004775b ffff82d040600000 ffff82d040600000 00215220 2**2 > CONTENTS, ALLOC, LOAD, READONLY, CODE > .... > > Some notes: > 1- I don't understand why the debug directory points to .buildid section > (I suppose that's the reason for the "There is a debug directory..." > message);
Like in ELF final executables, in PE ones information like this should be locatable by means other than looking up sections by name and then hoping they contain what's expected. Short of program headers and dynamic tags, this is the scheme people invented to make the build ID actually locatable. If you look at how this works in our build system, you'll find that this even requires passing a COFF object to the linker (i.e. involving a little bit of trickery). > 2- .buildid follows .rodata (this is expected); > 3- .buildid is not page aligned but the loader I tried seems to be > happy with that, > I think it should be aligned; Generally it doesn't need to be. If the secure boot stuff requires it to be, then we need to live with that (and the wasted page). Preferably it could continue to use (in the common case) a few bytes on the last .rodata page. Or we could see whether folding .buildid into .rodata works (I don't recall whether I tried that back at the time). > 4- .rodata for some reason is not marked as READONLY, even on ELF you > get the same issue. I can confirm this oddity, without having an explanation. It must be one of the inputs; I've checked that prelink.o's .rodata is r/o. So it can only be some other constituent. Jan
