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: [AVR][PATCH] Add linker relaxation support / Fix 64 bit bug in gas rev. 3


Nick Clifton wrote on Dienstag, 25. Oktober 2005 13:30 :
> Sorry - this patch introduces two new failures in the GAS testsuite for
> the avr-elf toolchain:
>
>    Running /sources/binutils/current/gas/testsuite/gas/all/gas.exp ...
>    FAIL: difference of two undefined symbols
>    FAIL: difference between forward references
>
I have analyzed the issue:

Presently during fixup cvs-gas rejects any calculation involving the 
difference of two lables during fixup:

void
md_apply_fix (fixS *fixP, valueT * valP, segT seg)
 [...snip...]
  /* We don't actually support subtracting a symbol.  */
  if (fixP->fx_subsy != (symbolS *) NULL)
    as_bad_where (fixP->fx_file, fixP->fx_line, _("expression too complex"));

*With* the patch the fixups are no longer done and relocations are silently 
generated without any check for validity of the expression. Symbols who'se 
value is unknown at assembly time and that should be added or substracted 
from another label are silently replaced by zero.

The result is that *with* my patch gas does assemble sources that did not 
assemble beforehand due to errors. It, thus, fails to issue the error message 
for unresolvable expressions.
I have already had a brief look, but I did not find so far a suitable target 
hook for inserting checking code for controlling if a relocation expression 
is acceptable or not.

> > I also have made use of <inttypes.h> in order to fix a bug that shows up
> > for 64 bit machines for present mainline.
>
> You should only use this header if HAVE_INTTYPES_H is defined.  If it is
> not defined you should provide an alternative definition of the types
> that you are using.
Basically the only thing I need for fixing the problem is an expression for 
"integer type that is large enough to hold a pointer". <inttypes.h> provides 
intptr_t that does the job. I thought this to be the cleaner way than simply 
using "(unsigned long long int)" for all of the targets. But if one could not 
assume that <inttypes.h> is present, I might as well use casts to long 
longs.? The difficulty shows up only at two places and is not performance 
relevant. However, I assume that a similar issue certainly shows up also 
elsewere in binutils, so that I think that there should be a standard method 
for this problem.?

Bjoern.

P.S.: 
>
> Cheers
>    Nick
Thank you for reviewing the patch.


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