https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124365
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #5) > (In reply to Richard Biener from comment #4) > > (In reply to Jakub Jelinek from comment #3) > > > It is not about debug info, but about linker behaving differently if all > > > the > > > linked *.o objects don't have the marking they are looking for. > > > > > > That is why we e.g. copy over .note.GNU-stack section, or > > > .note.gnu.property. > > > E.g. if we didn't copy .note.GNU-stack, the linked binary would be marked > > > as > > > (potentially) having executable stack because we couldn't prove otherwise > > > (because *.debug.temp.o files wouldn't tell). > > > > Oh, I see. Then that looks OK. I wonder if there's any good target hook > > (from common/) that we could use to make this more accessible. > > I'd say if it is conditionalized it should be done for ELF & EM_AARCH64, but > none of that is accessible to the function which filters these (unless it is > done in simple-object-elf.c (simple_object_elf_copy_lto_debug_sections) as > an exception next to the pfn call. OK, fair enough. > > > Note, while I've tested the patch on x86_64-linux and i686-linux so far > > > (where it doesn't break anything, quite obviously) and bootstrapped on > > > aarch64-linux, I'm still in make check there and only when that is over > > > will > > > test whether it fixed the actual problem (that -flto -g compiled/linked > > > binaries don't have the expected features). > > > > Adding a testcase should be possible (would fail only with new binutils, but > > still)? > > How? The testcase still links, but to test one needs to run > readelf/objdump/eu-readelf on the resulting binary. I thought ld can diagnose this at least? Can a run program query the state instead? I don't think we have any tests that examine the final binary in other ways.
