[Bug ld/19623] regression: missing relocation for symbols in discarded section

[address@hidden]

https://sourceware.org/bugzilla/show_bug.cgi?id=19623

--- Comment #2 from address@hidden ---
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.