[PATCH, gas] PC-relative fx_offset calculation

Chung-Lin Tang cltang@codesourcery.com
Wed Mar 6 06:37:00 GMT 2013

On 2013/3/4 08:04 AM, Alan Modra wrote:
> On Fri, Mar 01, 2013 at 10:02:53PM +0800, Chung-Lin Tang wrote:
>> > So how does this (one liner) patch look, does the change look sensible?
> No, it is not correct.  fx_where is supposed to be location of the
> field where the fixup is applied.  "dot" is not necessarily the same
> location.  For intstance, given a 4 byte instruction that consists of
> a 2 byte opcode followed by a 2 byte offset field, "dot" will point to
> the start of the insn but fx_where ought to point at the field.
> ie. fx_where = dot + 2.  However if you simply had a .short directive
> with the same fixup, then both "dot" and fx_where will point to the
> same location.

Thanks for the explanation, it makes things clearer.

It seems that fx_dot_value needs to be paired with the frag at the point
of saving, so here's a new patch that saves a pointer to the frag_now
along with dot_value. The pc-relative case now bases the calculation on
fx_dot_frag rather than fx_frag.

A few lines of comments in read.c:emit_expr() denoting the invalidating
of dot_value after frag_more() was also deleted, since I believe this is
not the case anymore after explicitly saving dot_frag/dot_value together.

This is only lightly tested so far, WDYT? (I believe this patch should
make more sense now...)


2013-03-06  Chung-Lin Tang  <cltang@codesourcery.com>

        * write.h (struct fix): Add fx_dot_frag field.
        (dot_frag): Declare.
        * write.c (dot_frag): New variable.
        (fix_new_internal): Set fx_dot_frag field with dot_frag.
        (fixup_segment): Base calculation of fx_offset with fx_dot_frag.
        * expr.c (expr): Save value of frag_now in dot_frag when setting
        * read.c (emit_expr): Likewise. Delete comments.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dotval.patch
Type: text/x-patch
Size: 3105 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20130306/c1c88423/attachment.bin>

More information about the Binutils mailing list