This is the mail archive of the binutils@sourceware.org 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: Commit: Patch: GAS: Fix DWARF line number generation for target that use linker relaxation


On Thu, Jun 28, 2012 at 05:03:21PM +0100, nick clifton wrote:
> Hi Alan,
> 
> >>+	  else
> >>+	    /* If the fix is valid, subtract fx_subsy here.  The addition of
> >>+	       fx_addsy will be performed below.  Doing this prevents bogus
> >>+	       warnings from the range check below.  */
> >>+	      add_number -= S_GET_VALUE (fixP->fx_subsy);
> >
> >This looks suspicious to me, as it applies a symbol value without any
> >sort of notification to the backend.  This ought to result in the
> >value being subtracted twice, unless the backend is buggy.
> 
> Hmm, are you saying that TC_VALIDATE_FIX_SUB ought to modify
> add_number directly, even though it is not an argument to the macro
> ?

No.

> The problem I was trying to fix was that (for the mn10300-elf
> toolchain) if TC_VALIDATE_FIX_SUB is invoked then, without my patch,
> add_number is left unmodified.  All the other alternatives in the
> if-statement from that code block update add_number (unless there is
> an error), so it seemed the correct thing to do.

When the other alternatives subtract the value from add_number, they
also set fx_subsy NULL.  Your patch will break eg. tc-xtensa.c
md_apply_fix as the fx_subsy value is subtracted there too.

> Also, without this patch, the mn10300-elf toolchain fails the
> gas/lns/lns-big-delta test because fixup_segment() erroneously
> complains that the value 75004 is being written to a 2-byte wide
> field.  The error is bogus because the actual value being written is
> 0.  The value of 75004 is obtained from fixp->fx_addsy, without the
> value of fixp->fx_subsy being subtracted.

tc-mn10300.c:md_apply_fix doesn't even consider fx_subsy when applying
a fully resolved fixup, so that's why you see a problem.  On looking
again, I see that mn10300 expects fx_addsy symbol values to be added
too (MD_APPLY_SYM_VALUE is 1).  So I think the correct solution is to
apply the fx_subsy values depending on MD_APPLY_SYM_VALUE, just as we
do for fx_addsy.

-- 
Alan Modra
Australia Development Lab, IBM


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