Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: VAX addressing modes
> Ok, here are excerpts from the asm output of gcc:
It's relevant to note that this is for different code (there are 7
cases, not 10, and the following code is different):
> .L7814:
> casel %r0,$0,$7
> .L3234:
> .word .L3233-.L3234
> .word .L3232-.L3234
> .word .L3235-.L3234
> .word .L3236-.L3234
> .word .L3237-.L3234
> .word .L3238-.L3234
> .word .L3239-.L3234
> .word .L3240-.L3234
> .L7810:
> movl 116(%r9),%r0
> jeql .L3169
> so this matches your description and makes sense. All .word were of
> the .L... - .L... form, nothing refers to absolute addresses or
> external symbols.
> Now back to the original question: the .word are 32bit offsets
> relative to the casel instructions?
Basically, yes. (Strictly, they're relative to the beginning of the
case table, just after the case instruction, but that's much the same
thing as far as relocations go.)
But note the relocation was two instructions after the last case
offset:
5ca19: 14 d2 case -> 0x59c1b
5ca1b: 38 45 case -> 0x60f3f
5ca1d: 31 06 00 brw 0x5ca26
5ca20: 17 9f cf 76 jmp *$000676cf
06 00
5ca22: R_VAX_RELATIVE *ABS*+0x676cf
5ca26: dd 5a pushl r10
The relocation applies to the target of the jmp instruction, not to one
of the case offsets. (The jmp instruction can be is reached via one of
the arms of the case, but that's not relevant to the relocation.)
The casel instruction was mostly a red herring; it was relevant only in
that it led the binutils disassembler to disassemble the code such that
the jmp instruction didn't disassemble as a jmp and thus the relocation
target looked like something other than what it actually was.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index