This is the mail archive of the
mailing list for the binutils project.
Re: GAS (ARM): Possible bug in relative/relocatable address detection
- From: Jens Bauer <jens-lists at gpio dot dk>
- To: Alan Modra <amodra at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 29 May 2013 16:39:43 +0200
- Subject: Re: GAS (ARM): Possible bug in relative/relocatable address detection
- References: <20130528004017761596 dot 7c67cd64 at gpio dot dk> <20130528002342 dot GC6878 at bubble dot grove dot modra dot org> <20130528031318207293 dot ff43c7c2 at gpio dot dk> <20130528015648 dot GD6878 at bubble dot grove dot modra dot org> <20130529144604402815 dot c516ad73 at gpio dot dk> <20130529140152 dot GL6878 at bubble dot grove dot modra dot org>
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? :)
> #define TC_FORCE_RELOCATION_SUB_SAME(FIX, SEG) \
> (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.