|How can a disassembler tell code from data? firstname.lastname@example.org (1991-05-09)|
|Re: How can a disassembler tell code from data? email@example.com (1991-05-11)|
|From:||firstname.lastname@example.org (Ron Guilmette)|
|Organization:||Network Computing Devices, Inc., Mt. View, CA|
|Date:||11 May 91 18:30:57 GMT|
In article <email@example.com> firstname.lastname@example.org (David E Wexelblat) writes:
>... My problem is trying to disassemble code compiled with GCC,
>which puts constant character strings into the text segment...
>... I would like a general-case answer, but the
>following constraints can be applied, if necessary:
> 3) COFF format object files
The general case answer is to stop using COFF and use ELF instead.
In ELF, constant data can go into the .rodata or .rodata1 *sections*. The
linker will normally combine all input .rodata sections (for all of the .o
files given to it as inputs) into one hunk of output .rodata stuff and it
will normally attach that to the output .text *segment*, however you can
use the MAPEFILE option to override this behavior and to get all of the
.rodata stuff placed into its own unique (LOADable) output segment. You
could then just ignore that output segment when doing your disassembly.
Actually, you do not even need to use the MAPFILE option (necessarily).
As long as you do not strip the executable, it will include both a segment
header table *and* a section header table. In the section header table
there will be one entry for the collected sum of all of the input .rodata
sections. This header will indicate where (within the executable) the
start and end of all of the .rodata stuff is. You could then just ignore
anything in that range.
You may be able to duplicate one or both of these techniques with COFF,
but I'm not sure.
// Ron ("Loose Cannon") Guilmette
// Internet: email@example.com uucp: ...uunet!lupine!rfg
Return to the
Search the comp.compilers archives again.