'broken words' misbehavior?

[Hans-Peter Nilsson]

On Thu, 22 Feb 2007, Jan Beulich wrote:
> This piece of code
>
> 	.data
> table:
> 	.org table + 8
> end:
> 	.word end - table + 0x8000
>
> 	.text
> start:
> 	ret
>
> causes two jumps (a short and a long one) to be inserted right before 'start'
> (i386 or x86-64). While I understand that this is caused by the logic dealing
> with 'broken words', I can neither see what's wrong (or even in need of
> special treatment) with the code above,

(int16_t) (end - table + 0x8000) != (int32_t) (end - table + 0x8000)

> nor do I understand what these
> jumps are supposed to help with (in general, and even more in the given
> case, where there isn't any code needing fixing up).

It's a gas "feature" to help dealing with case tables (from gcc)
that overflow.  Suggested reading: write.c:2011.

> Also, I don't have an idea how to work around it in the general case (older
> assemblers also choke on .skip or .fill instead of .org, but that seems to
> have gone with the improvements to expression evaluation, so for
> compatibility reasons I can't use either of those).

Your target (you don't say, but presumably i386/x86_64) should
"#define WORKING_DOT_WORD".  Almost all targets do that.  Does
that target *really* (still?) need this feature?

If you instead decide to hack^Wfix this feature, there are
test-cases in the cris testsuite, cris-axis-elf.  The feature is
not ready for removal, yet.

brgds, H-P