Merge .openbsd.randomdata.* sections into a single .openbsd.randomdata section when linking.
Can you describe the purpose of the section and why it needs to be suffixed? If .openbsd.randomdata. is only used in very few places, writing a linker script is a more appropriate solution.
This patch needs a test case in section-name.s if it is justified.
I spoke to the author of the diff and asked for some feedback. He said...
Picking a random userland .o file from the build: readelf -a shows that it
contain multiple randomdata sections:
.openbsd.randomdata.retguard.130 .openbsd.randomdata.retguard.236 .openbsd.randomdata.retguard.2936 .openbsd.randomdata.retguard.443 .openbsd.randomdata.retguard.2600
The suffix here is a hash generated by the compiler. This is something
done by default by the compiler on openbsd, so if we were to instead use a
linker script for this then (almost) *EVERY* program built on openbsd
would require a linker script.
As for "isn't this useless without putting them in PT_OPENBSD_RANDOMIZE
segment", well, sure, so add the four chunks under gnu/llvm which define &
mention that symbol...but I think some may argue that doing that should
only be done if the binary's 'OS' field in the header is the openbsd
value, so that may create a different kind of pushback.
Well, if the default compiler on openbsd does it, I think the change is reasonable. @MaskRay?
This patch, as was mentioned, needs a test case.
Also, I believe LLD already creates the PT_OPENBSD_RANDOMIZE segment and adds the .openbsd.randomdata
section to it already in Writer.cpp:
// PT_OPENBSD_RANDOMIZE is an OpenBSD-specific feature. That makes // the dynamic linker fill the segment with random data. if (OutputSection *cmd = findSection(".openbsd.randomdata", partNo)) addHdr(PT_OPENBSD_RANDOMIZE, cmd->getPhdrFlags())->add(cmd);