This is the mail archive of the 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: GAS (ARM): Possible bug in relative/relocatable address detection

Hi Alan.

Please forgive me for any possible misunderstandings in advance. ;)

> /* Force output of R_ARM_REL32 relocations against thumb function symbols.
>    This is needed to ensure the low bit is handled correctly.  */

Question: *Is* the low bit actually handled correctly, or is this just the easiest way to fix the problem? :)

>   (THUMB_IS_FUNC ((FIX)->fx_addsy)		\
>    || !SEG_NORMAL (SEG))
> So the subtraction isn't allowed, the subtrahend is converted to a
> pc-relative value

To me it smells a bit like a quickfix; is this because the linker does not know how to do a bitwise OR operation ?
Shouldn't the symbol have its low-bit set, before the relocation occurs?
Eg. relocation will never add an odd value to a relocatable address anyway, correct?
(unless the whole section is aligned on an odd byte, that is; but if so, the user is begging for trouble anyway.)

Anyway, logically, still...
subtracting a relocatable thumb-function from a relocatable thumb-function should still give a 'distance' or a 'relative value'.
...Adding a relative value to a relocatable thumb-function would produce a relocatable thumb-function.
So if the assembler uses flags for both 'relocatable' and 'thumb function', then both would need to be taken into consideration during the evaluation of the entire expression.
Of course, it might be tricky to evaluate an expression like relocatable + relocatable - relocatable, unless having a counter instead of just a 'bit'. Same goes for 'thumb' and any other kind of flag that sticks to a symbol. Having a bit-flag isn't really enough.

> and then we run into lack of a suitable 16-bit pc-relative relocation.
> Your wrapping of the subtraction avoids this check, which I suppose is
> a bug, but you might see it as a feature..

Let's say it's a feature (when you know what you want and need to find a way how to get there). ;)

The trouble is that without being able to find the difference between two thumb-labels, using the TBB and TBH instructions might get quite difficult.
Then one would have to generate shadow-labels that are non-thumb labels and use those (argh). That's OK for one 3-entry table, but if your code contains 7 tables of 500+ entries each, you just *don't* want to do that.


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