Wed, 12 Sep 90 12:06:53 -0400

          From comp.compilers

Related articles
Disassembly phorgan@cup.portal.com (1990-09-09)
Disassembly meissner@osf.org (1990-09-12)
Re: Disassembly pl@news.funet.fi.tut.fi (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 aglew@dwarfs.crhc.uiuc.edu (1990-09-19)
Re: Disassembly chris@cs.UMD.EDU (1990-09-20)
| List of all articles for this month |

Newsgroups: comp.compilers
From: meissner@osf.org
In-Reply-To: phorgan@cup.portal.com's message of 9 Sep 90 17:32:55 GMT
Keywords: assembler, debug
Organization: Compilers Central
Date: Wed, 12 Sep 90 12:06:53 -0400

| The problem with disassembling arbitrary object code is that data bears a
| disturbing resemblance to code at times:) Even when running through code
| disassembling starting at known code, it's not always possible to
| determine when code stops and data begins. Then it's not possible to tell
| when object code starts up again.

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

Thus on a MIPS system, you don't have to worry about data being in the
text section.... (and of course each instruction is exactly 32-bits,
so you don't have to worry about starting in the middle of an
instruction, like you do on CISC machines.

| This is easy to see using most
| dissassemblers; when you hit the data, the unknown op-code indicator
| appears (typically ???), then random sequences of ??? and op-codes, then
| when the code starts, often the disassembler has just guessed wrong and
| includes the first byte or two of the 'real' op-code in a previous 'false'
| one. It might take a while to 're-synchronize' and start showing 'real'
| op-codes. The only time this isn't a problem would be with fixed single
| length op-codes with an alignment requirement. It is possible to reduce
| the problem with an algorithm that looks ahead starting byte-by-byte and
| sees which one generates a most successful string of instructions. From a
| 'good starting byte', you could disassemble in reverse to find a previous
| starting location.

You could always do a complete scan of the text, using a bitmap or
some such to identify every place that has an instruction. It would
have to be a backtracking scan, so that you can mark both the fall
through case, and conditional branch target cases. IMHO though, it
would be too slow and consume too much memory to be useful.

| Even this fails in many cases of self modifying code
| or in cases where strange things are done like overlapped code. ...

Fortunately for this case, self modifying code seems to be mostly on
the decline, and only used where needed (or because you have a macho
hacker type that thinks self modifying code is neat).

Michael Meissner email: meissner@osf.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.