Workaround or Solution Needed for .h/.l Relocation in 6800 Assembler

[zu2]

Relocatable code cannot be properly generated with .h and .l expressions in the 6800 assembler, as also indicated in comments of 6500/as/mach4.c:

 * The .h and .l extensions of expressions are vital.  However, they prevent
 * relocatable code from being generated.  Consider the following example:
 *
 * (file 1)
 * .sect .text          ! 1
 * lda #[endbss].l              ! 2
 * ldx #[endbss].h              ! 3
 *
 * (file 2)
 * .sect .bss           ! 4
 * endbss:                      ! 5
 *
 * Wat voor relocation struct moet er nu voor de instructie in regel 3
 * worden geproduceerd?
 * 
 * What kind of relocation structure needs to be generated for the instruction
 * in line 3?

On MC6800, address calculations like for global array elements require:

ldab #[_var].l
ldaa #[_var].h
addb _off+1
adca _off

Due to this limitation, the assembler cannot generate such code, resulting in inefficient or complicated output.

Are there any known solutions, workarounds, or community-contributed examples for dealing with this situation? Any shared experience would be very helpful.

[davidgiven]

Huh. Having looked at h/out.h, which defines the object file format, that's not supported, which surprises me.

That said, it doesn't look trivial. The way relocations are stored are as symbol+offset, where the offset is in the instruction operand bytes in the object file. The relocation table just contains the symbol reference. When led does the relocation it will look up the symbol address and then add that to the operand bytes. This means that if you're fixing up an address, led will need access to both the high byte and the low byte in order to determine the correct offset. It's not good enough just to add a single high-byte-of-address fixup.

The way led currently handles weird fixups is to have a platform-specific fixup type, which points at the opcode byte. The led code then looks at the opcode bytes and figures out what to do. So there could be a RELO68xx relocation type, of width 2, which when pointed at two consecutive ld instructions would fill in the operands. You'll probably want one of these anyway in order to handle computing the offset in relative branch instructions. It can be the same fixup, as led can distinguish between use cases by the opcode.

I'll take a look at this at some point, but if you want to check it out in the mean time, look at h/out.h and util/led/relocate.c, where all the relocation logic is. It should be fairly clear.