Re: Objdump on VAX

["Maciej W. Rozycki" <macro at linux-mips dot org>]

On Mon, 29 Nov 2004, Jan-Benedict Glaw wrote:

> > function-by-function basis (this is how you get disassembly and raw output
> > interspersed depending on symbol types for "-d" for MIPS/ELF), so padding
> > is not a problem -- just dump trailing bytes as raw data (or "...") as
> > they don't form a complete instruction anyway.  You probably also want to
> 
> Actually, they do, unfortunately! 0x00 isn't much of a problem (one-byte
> instruction HALT), but I've seen random data at some functions (not
> neccessarily GCC/gas' output). ...and with the PITA of variable-length
> instructions, this garbage can resemble something remotely "useful".

 You can have trailing garbage, but you won't cross a function boundary.

 With the GNU tools you shouldn't have random stuff being used for filling
gaps -- it looks like a bug somewhere.  The easiest choice is an
instruction that acts as a "nop" and is one byte long if you have such --
what's your default filler for the ".align" "as" directive?  "Halt"  
doesn't sound too optimistic.  You may use a fancier approach
alternatively, like e.g. the i386 target does.

> >  Note that you probably need to find a reasonable way of treating both
> > "-d" and "-D" and cases when a symbol table is available or not.
> 
> I think you can't fix any of those when there's no symbol table. This
> would require objdump knowing the actual execution address (think of ROM
> contents) as well as some kind of entry point to search for function
> CALLS'/CALLG's. With no symbol table, the best output would be "nothing
> useful to present".

 Well, that'd be for "-d" -- for "-D" I think you should just disassemble 
everything as is, perhaps even when there is adequate symbol information.

> If you just start disassembling as some address, you don't get anything
> useful. Even if you omit the very first two bytes (in the hope this is a
> function's entry mask), you'll somewhen reach another function's entry
> mask. Unfortunatley, these *do* sometimes disassemble to useful
> assembler statements, and if this opcode (with it's assigned data)
> doesn't have the length of two bytes, you're foobared...

 Sure -- you just get what you've asked for.  Use "--start-address" for
finding the right entry point.  You do want to have a way to disassemble
from the "binary" BFD, like with your ROM.  "Ksymoops" may also want that.

  Maciej