|Disassembly email@example.com (1990-09-09)|
|Disassembly firstname.lastname@example.org (1990-09-12)|
|Re: Disassembly email@example.com (1990-09-14)|
|Re: Disassembly Chuck.Phillips@FtCollins.NCR.COM (1990-09-14)|
|Disassembly tmsoft!mason@uunet.UU.NET (1990-09-15)|
|Re: Disassembly albaugh@dms.UUCP (1990-09-17)|
|Re: Disassembly firstname.lastname@example.org (1990-09-19)|
|Re: Disassembly chris@cs.UMD.EDU (1990-09-20)|
|From:||email@example.com (Lehtinen Pertti)|
|Organization:||Finnish University and Research Network FUNET|
|Date:||Fri, 14 Sep 90 14:40:01 GMT|
>From article <9009121606.AA26236@curley.osf.org>, by firstname.lastname@example.org:
> | The problem with disassembling arbitrary object code is that data bears a
> | disturbing resemblance to code at times:) ...
> I discovered that the MIPS assembler has a 'solution' to this problem.
> It doesn't prohibit you from putting constants in the text section,
> but if you do, the line numbers for debugging are messed up. I found
> this when I had GCC putting the switch label array in .text. The MIPS
> people I talked to about this said it was a feature, and not a bug....
I once wrote a disassembler for Z80. It started on given address and put
every jump or call destination into heap. When it hit rts, or other
stopping intruction, it picked next address from heap and continued. So I
was able to find all possible control flows forward from given place.
This was nice feature when looking at interrupt services and such things.
And it never dropped from sync, because it followed same paths as
Of course indirect jumps could cause problems.
On Sparc we hit one problem on disassembly (not actually but...)
Memory addressing on sparc is always register relative (no 32 absolute
addressing) so it is sometimes hard to find out, which symbol is accessed,
because base register initialization could be quite far away.
Tampere University of Technology
Software Systems Laboratory
Return to the
Search the comp.compilers archives again.