Re: VAX addressing modes

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

On Thu, 27 Jul 2017, Mouse wrote:

> > In objdump -dR output, the code looks like:
> 
> >    5ca00:       31 de db        brw 5a5e1 <Perl_yylex+0x2e6f>
> >    5ca03:       cf 50 00 0a     casel r0,$0x0,$0xa
> >    5ca07:       27 11 38 45     divp $0x11,$0x38,$0x14[r5],*0xffffd214(r2),*0x46
> > (r0),*0x46(r0)
> >    5ca0b:       14 d2 14 d2 
> >    5ca0f:       b0 46 b0 46 
> 
> This is pretty obviously not code (that divp makes no sense).  The
> disassembler is defective; it is failing to understand that casel is
> followed by a jump table, not ordinary code.

 FYI, `objdump' uses symbol types rather than heuristics to determine 
whether to dump binary contents as code or data.  This is especially 
because you can request an arbitrary range to be dumped and looking back 
for any preceding instruction that could change interpretation is 
infeasible.

 Therefore the correct solution is to insert a symbol of the data type 
(STT_OBJECT in ELF-speak) at the beginning of any text content that is 
supposed to be intepreted as data and then a symbol of the code type 
(STT_FUNC in ELF-speak) at the end (if applicable).  This has to be done 
by the compiler (or whoever has written handcoded assembly code).  Some 
GCC target backends do this already, the VAX one clearly does not, as 
shown by this example.

  Maciej