Re: Objdump on VAX

[Jan-Benedict Glaw <jbglaw at microdata-pos dot de>]

On Mon, Nov 29, 2004 at 07:21:01PM +0000, Maciej W. Rozycki wrote:
> On Mon, 29 Nov 2004, Jan-Benedict Glaw wrote:
> > However, this breaks if previous function's padding bytes make of a
> > long opcode which spawns into the new function...
> 
>  See how disassemble_bytes() is called -- it works on a

I'll check, thanks.

> 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".

> treat the leading two bytes this way (or maybe using a somewhat more fancy
> output), but disassemble_bytes() and its worker disassembly function do
> not get passed the associated symbol's type attribute.  I guess passing it
> as an additional argument might be the easiest solution, but not
> necessarily the best -- others may have different proposals.  Or perhaps
> just do that unconditionally.

Perheps I'll try some implementation of this and present it for revies.

>  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".

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...

But many thanks for the hints, I'll start over with it!

MfG, JBG

-- 
AWEK microdata GmbH -- Am Wellbach 4 -- 33609 Bielefeld