Julian Waters <tanksherma...@gmail.com> writes: > 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
A minimal (ideally C) source file with a small set of commands to produce obviously bad assembly or an abort on e.g. a bad runtime condition. This makes it easy to analyse, for people to help, and ultimately for it to be added to the testsuite. Trying to debug a massive source file as-is withou reducing it is not fun. > > movabsq $8+__gcov_indirect_call@secrel32, %rax
