https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #10 from mintsuki <mintsuki at protonmail dot com> --- (In reply to H.J. Lu from comment #8) > (In reply to mintsuki from comment #7) > > (In reply to H.J. Lu from comment #5) > > > (In reply to mintsuki from comment #3) > > > > Also, when generating a shared object with -shared, without -pie, > > > > having a > > > > non-0 base address does not affect the ELF file type, which is always > > > > > > You can't load the multiple shared libraries at the overlapping address > > > range. > > > > > > > ET_DYN. If what you just said is true, then why is this the behaviour > > > > here > > > > and not when making a static PIE? > > > > > > A testcase? > > > > I was asking a testcase of static PIE where ELF type wasn't EXEC when a load > address was specified. There is no such case for ld.bfd. I never said there was, sorry if I wasn't clear enough. That said, lld and gold both allow for such case as previously mentioned. What I believe the bug consists of is the behaviour of ld.bfd not aligning with the other linkers. I think it makes perfect sense for an ET_DYN static PIE with non-0 load address to exist, as previously mentioned, and I believe the bug is ld.bfd not allowing this. If this is policy, then I believe it should be properly documented somewhere, if it wasn't already, and then ld.gold (as part of GNU binutils) should be changed to match ld.bfd's behaviour. Though I hope this isn't done as I consider ld.gold's (and LLD's) behaviour to be the preferrable one. -- You are receiving this mail because: You are on the CC list for the bug.
