This is the mail archive of the
mailing list for the binutils project.
Re: Objdump on VAX
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.