i386 struct disassemble_info

Nick Clifton nickc@redhat.com
Tue Feb 27 12:11:00 GMT 2007


Hi Lucian,

> A project I'm working on needs to get all function calls from an input
> object file.
> 
> Some of it's fields are not completed when I disassemble an
> instruction on i386 but are completed for other architectures (sparc
> for example).
> 
> The one I'm most interested is insn_type.

Right.  This field is currently only set by those architectures that 
actually need it for some reason.

> I would like to know if there is a more straight forward & PORTABLE
> way to do this.

Sadly no.  Determining which instructions are function calls is always 
going to be an architecture specific operation.  In fact you may never 
be able to extract all the function calls from a binary because:

   * The compiler might have inlined one function inside another, 
eliminating a call to that function altogether.

   * The function call might be via a pointer held in a register, and 
thus the destination of the call might not be predictable.

   * The function call might be to a weak alias whose real name will not 
be known until the final link has completed.

   * Sometimes the jump-to-subroutine instruction in an instruction set 
is used as a branch instruction, not a function call instruction.  Also 
sometimes functions are called via a branch-to-address type instruction 
instead of a jump-to-subroutine instruction.  (In the case of tail-calls 
for example).


> If not I'd have to create a parser for every type of ASM syntax
> supported by libopcodes (this means AT&T and Intel for i386, but
> there's more to it than i386).

The cleanest way would be to add code to set the insn_type field for 
those targets which currently do not set it, and which you are 
interested in.  This will not be perfect, but it would be safer than 
trying to parse the textual output of the disassembler.


> PS: if there's a libopcodes "tutorial" out there plese point me to it.

Sorry, there is no such thing.  In this case the source code is your friend.

Cheers
   Nick



More information about the Binutils mailing list