This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] MIPS: Follow the ABI rules for ordering HI16_S/LO16relocs


"Dave Korn" <dk@artimi.com> writes:
>   I can see the difficulty in calculating a high part if there's a
> sign-extended carry from the low part that you don't know about, but I don't
> see why lo16 calculations can't stand entirely by themselves if they need.

Mergeable sections are something of a special case.  Say you have:

g:      .word   1
h:      .word   2

in a section where identical words can be merged.  There's no guarantee
that "g" and "h" will be next to each other in the final output.

Therefore, if you take the address "g + 4", the linker has to know that
you want the address of a ".word 1" with 4 added to it, not the address
of a ".word 2".

If you generate a relocation of the form "g + OFFSET", then the linker
will use the symbol ("g") to identify which bit of data you're actually
interested in.

However, you can also have relocations against mergeable section symbols.
In this case, it's the addend rather than the symbol that identifies the
data.  The problem for REL targets is that you need to recalculate the
complete offset in order to identify the data correctly.

Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]