Resending again as I forgot to send it to the list > Sorry, I somehow missed it. :-( Then a configure check should be added in the > compiler to tell whether the detected linker has the fix or not.
> There are already some specific checks for the PE linker at configure.ac:6500, > although they do not invoke it. A model could be the linker check "linker EH > garbage collection of sections bug" at configure.ac:6295 and the check could > use one of tests that Jan enabled in the linker testsuite (secrel-reloc.d). Haha, no worries. I'll see what I can do there. No promises that I can figure it out on my own though, since gcc's build system has confused me to no end, I'll ask for help again if I need to > Do you have a testcase for this particular issue? I'm not quite sure what you mean by a testcase, but when compiling gcc itself, when libgomp/libgcc (Can't remember which) is being compiled, gcc will spit out invalid assembly that looks something like movabsq $8+__gcov_indirect_call@secrel32, %rax This is, of course, not correct, since movabsq takes a 64 bit value, but @secrel32 is 32 bit. The RTL code in legitimize_tls_address that was responsible for this assembly is rtx base = gen_reg_rtx (Pmode); emit_insn (gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, gen_rtx_SET (base, gen_rtx_UNSPEC (Pmode, gen_rtvec (1, const0_rtx), UNSPEC_TLS_WIN32)), gen_rtx_CLOBBER (VOIDmode, gen_rtx_SCRATCH (Pmode))))); return gen_rtx_PLUS (Pmode, base, gen_rtx_CONST (Pmode, gen_rtx_UNSPEC (Pmode, gen_rtvec (1, x), UNSPEC_SECREL32))); // This is the code that results in the broken assembly! This issue has been frustrating me to no end, since you can't add Pmode to SImode normally, but then making the UNSPEC Pmode results in the broken assembly shown above. The only solution I've found that works is zero extending the UNSPEC const to Pmode, but that causes a useless register load to appear: leal local@secrel32, %edx Right now I'm working on trying to find out how to make the zero_extend a compile time no-op, but no luck there :( best regards, Julian On Mon, Oct 7, 2024 at 3:26 PM Eric Botcazou <botca...@adacore.com> wrote: > > The linker bug blocking this patch has actually already been fixed, see > > > https://github.com/bminor/binutils-gdb/commit/72cd2c70977943054ff784b7278cef > > 5262288f32 for the patch that fixed it (Thanks for the help Jan!). > > Sorry, I somehow missed it. :-( Then a configure check should be added in > the > compiler to tell whether the detected linker has the fix or not. > > There are already some specific checks for the PE linker at > configure.ac:6500, > although they do not invoke it. A model could be the linker check "linker > EH > garbage collection of sections bug" at configure.ac:6295 and the check > could > use one of tests that Jan enabled in the linker testsuite (secrel-reloc.d). > > > I'll add your suggestions to the patch before pushing out a new version > for > > review, thanks (Well, there is one suggestion of yours I cannot add: > Making > > the secrel32 relocation Pmode, since the emitted assembly is broken when > I > > do that) > > Do you have a testcase for this particular issue? > > -- > Eric Botcazou > > >
