https://sourceware.org/bugzilla/show_bug.cgi?id=19623
--- Comment #2 from winter-...@bfw-online.de --- Hi Nick, so it is quite hard to make up the scenario as one needs to design a COFF structure just like the problematic one. Maybe debugging the linker can resolve this more quickly. While debugging the linker (recent version at commit 33b4777ca1b) I verified some of my claims. It now appears that a) the macro discarded_section (sec) on sec returns false because bfd_is_abs_section (sec) is true, so no "continue" statement happens b) if one adds "sec->output_section->vma == 0" as entry condition for the branch, the call of _bfd_clear_contents has an impact on the resulting relocation address (being wrong, but still somewhat changed from the original state) > This intrigues me, and I suspect is the core of the problem. In fact, actually there seem to be two problems (a, b). > Do you have any > idea as to why this should make a difference ? On the surface the purpose > seems > clear: the reloc being cleared references a section that is going to be > discarded. so there is no point in processing, or retaining, the reloc. Well, my understanding of the code and the COFF structure in general is somewhat limited and I am having a hard time understanding why the error occurs and what exactly the error is since the current "fix" is to continue the loop execution which actually prevents a call to _bfd_final_link_relocate in line 3107. Yet the resulting broken file seems like an object file where relocation did not occur. How could the "continue" statement in the block for handling discarded sections trigger a relocation when the code indicates the opposite? > Please do try - I think that we are going to need one. > > If we are going to have to make an SCO specific patch, (which is > undesirable, but appears to be the case in this situation), then we will > need a way to make > sure that it works, and that it does not break other COFF targets. Sure, I will keep trying to create a minimal test case. For now I will attach some debug logs so the internal state at the erroneous situation is visible and might gain some insights. In my first post I suggested that one function of my two functions was relocated correctly or luckily did not require relocation and this stayed functional. I discovered that the symbols of the functions have different storage classes which might have an impact on relocation: [ 13](sec 1)(fl 0x00)(ty 0)(scl 6) (nx 0) 0x00006af4 foo_patch [121](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00006b0c bar_patch Regards, Leon -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils