In the Xen project, to test the internal insn emulator, we have a simple way of generating binary blobs to hand to the emulator: %.bin: %.c $(CC) $(filter-out -M% .%,$(CFLAGS)) -c $< $(LD) $(LDFLAGS_DIRECT) -N -Ttext 0x100000 -o $*.tmp $*.o $(OBJCOPY) -O binary $*.tmp $@ Up to 2.35 this has been working fine. The introduction (by default) of the .note.gnu.property section has led to all of the resulting *.bin files to be about 128Mb in size. Such options causing extra content to be created should imo never default to true.
It sounds like .note.gnu.property section is unused. Please pass -R .note.gnu.property to objcopy to remove it.
(In reply to H.J. Lu from comment #1) > It sounds like .note.gnu.property section is unused. Please pass > -R .note.gnu.property to objcopy to remove it. That's what I'm meaning to do as a workaround, but as per https://lists.xen.org/archives/html/xen-devel/2021-04/msg01002.html there are reservations against this approach. No workaround should have been necessary here in the first place. Perhaps the issue wouldn't have occurred if the section hadn't SHF_ALLOC set. Is there a specific reason for this? The gABI looks to mandate the flag to be clear for SHT_NOTE type sections.
(In reply to Jan Beulich from comment #2) > (In reply to H.J. Lu from comment #1) > > It sounds like .note.gnu.property section is unused. Please pass > > -R .note.gnu.property to objcopy to remove it. > > That's what I'm meaning to do as a workaround, but as per > > https://lists.xen.org/archives/html/xen-devel/2021-04/msg01002.html > > there are reservations against this approach. No workaround should have been > necessary here in the first place. > > Perhaps the issue wouldn't have occurred if the section hadn't SHF_ALLOC > set. Is there a specific reason for this? The gABI looks to mandate the flag > to be clear for SHT_NOTE type sections. All note sections in Linux binary have SHF_ALLOC: [ 2] .note.gnu.build-id NOTE 004001d0 0001d0 000024 00 A 0 0 4 [ 3] .note.gnu.property NOTE 004001f4 0001f4 000034 00 A 0 0 4 [ 4] .note.ABI-tag NOTE 00400228 000228 000020 00 A 0 0 4
This is the status quo. The trend is more and more enabled-by-default security hardening features. They need markers in object files and linked images. Many firmware/freestanding style builds don't like such features. They have to opt opt, e.g. -fno-pic -fno-stack-protector -fstack-check-no -fcf-protection=none -no-pie xen was relying on a non-guaranteed layout.
(In reply to Fangrui Song from comment #4) > xen was relying on a non-guaranteed layout. And how would you suggest we prevent such happening again, in case yet more stuff gets added to images by default? We can't really predict (read: guess) e.g. suitable -R options to pass to objcopy. As I also can't spot any justification in any of the earlier comments that this is "not a bug", I'm further putting the entry here back to "unconfirmed". Comment 3 saying "All note sections in Linux binary have SHF_ALLOC" is an observation, but not an answer to my question, which was referring to the gABI. If the gABI is violated, then the note sections in Linux ought to be fixed imo. Which in turn would prevent .note.* related issues like this one to occur again going forward.
A dynamic loader needs PT_GNU_PROPERTY to know the ISA usage of a component. .note.gnu.property makes up PT_GNU_PROPERTY. Therefore, the section needs to SHF_ALLOC to be part of the program image. % cat a.c int main() {} % gcc -o a a.c -nostdlib -Wl,-N -static -Wl,-Ttext=0x10000 -fuse-ld=bfd /usr/bin/ld.bfd: warning: cannot find entry symbol _start; defaulting to 0000000000010000 If you use objcopy -O binary, you will notice that the output as 4mib. Why? Because the linker generates .note.gnu.build-id . You need -Wl,--build-id=none to remove it. [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 0000000000010000 000190 00000b 00 WAX 0 0 1 [ 2] .note.gnu.property NOTE 0000000000400190 0001d8 000030 00 A 0 0 8 [ 3] .note.gnu.build-id NOTE 00000000004001c0 000208 000024 00 A 0 0 4 [ 4] .eh_frame PROGBITS 0000000000010010 0001a0 000038 00 A 0 0 8 [ 5] .comment PROGBITS 0000000000000000 00022c 00002e 01 MS 0 0 1 [ 6] .symtab SYMTAB 0000000000000000 000260 000120 18 7 7 8 [ 7] .strtab STRTAB 0000000000000000 000380 000022 00 0 0 1 [ 8] .shstrtab STRTAB 0000000000000000 0003a2 00005a 00 0 0 1 You may use -Wa,-mx86-used-note=no to remove .note.gnu.property GNU ld -z separate-code has a separate issue, the segment layout isn't particular good: https://sourceware.org/bugzilla/show_bug.cgi?id=24490 two R around RX are wasteful. Ideally there is only one R and it precedes RX.
(In reply to Fangrui Song from comment #6) > A dynamic loader needs PT_GNU_PROPERTY to know the ISA usage of a component. > .note.gnu.property makes up PT_GNU_PROPERTY. Therefore, the section needs to > SHF_ALLOC to be part of the program image. You fail to address my pointing out of this not being compliant to gABI. I also don't buy the argument that the dynamic loader needs the note sections mapped into memory. It can very well simply read them from the file. (I can see that it's _easier_ if they get mapped, but that's not an excuse to violate gABI, which I assume has good reasons to state what it states.) > If you use objcopy -O binary, you will notice that the output as 4mib. Why? > Because the linker generates .note.gnu.build-id . You need > -Wl,--build-id=none to remove it. > [...] > You may use -Wa,-mx86-used-note=no to remove .note.gnu.property This doesn't address my question as to making oneself immune to future such binutils changes.
If you don't need NOTE sections, just discard them in the linker script.
(In reply to H.J. Lu from comment #8) > If you don't need NOTE sections, just discard them in the linker script. As per above there's no linker script involved here, and for the simple purposes here there imo shouldn't be such a requirement imposed by changes to binutils. IOW I don't view this as an answer to my request.
(In reply to Jan Beulich from comment #9) > (In reply to H.J. Lu from comment #8) > > If you don't need NOTE sections, just discard them in the linker script. > > As per above there's no linker script involved here, and for the simple > purposes here there imo shouldn't be such a requirement imposed by changes > to binutils. IOW I don't view this as an answer to my request. Please try this linker script: SECTIONS { /DISCARD/ : { *(.note.*) } } INSERT AFTER .text; This should discard all note sections.