Path: utzoo!attcan!uunet!world!esegue!compilers-sender
From: pl@news.funet.fi.tut.fi (Lehtinen Pertti)
Newsgroups: comp.compilers
Subject: Re: Disassembly
Keywords: assembler, debug
Message-ID: <1990Sep14.144001.15680@funet.fi>
Date: 14 Sep 90 14:40:01 GMT
References: <9009121606.AA26236@curley.osf.org>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: pl@news.funet.fi.tut.fi (Lehtinen Pertti)
Organization: Finnish University and Research Network FUNET
Lines: 36
Approved: compilers@esegue.segue.boston.ma.us

>From article <9009121606.AA26236@curley.osf.org>, by meissner@osf.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
execution.

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.

--
pl@tut.fi
Pertti Lehtinen
Tampere University of Technology
Software Systems Laboratory
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{ima | spdcc | world}!esegue.  Meta-mail to compilers-request@esegue.