|Help Needed for sparc object hackery firstname.lastname@example.org (1993-07-22)|
|Re: Help Needed for sparc object hackery email@example.com (1993-07-23)|
|Re: Help Needed for sparc object hackery firstname.lastname@example.org (1993-08-02)|
|From:||email@example.com (David Keppel)|
|Organization:||Computer Science & Engineering, U. of Washington, Seattle|
|Date:||Fri, 23 Jul 1993 19:35:56 GMT|
In 93-07-070 firstname.lastname@example.org (Bobby Sardana) writes:
>1. Analyse a given executable on Sun4 architectures. (Format is BSD-COFF).
It is hard, in the general case, to examine an arbitrary executable and
determine what is code and what is data. Even if the program avoids
self-modifying code and related techniques, it is not enough to rely on
the marked text and data sections, as constant data is often loaded in the
text section; many compilers do this with strings, for example. Analysis
can be difficult; rewriting "real" text without rewriting the data also,
doubly so. Here, "hard" means something like "a solution to the halting
problem" (though I lack a formal proof).
This problem is something to be remembered when saying "we implemented our
tool to run over assembly code, but it would also work with machine
(object) code", since the two problems aren't usually equivalent. Better
symbol table information can ease the problem, but few systems provide
such good symbol table info.
For a brief discussion see:
%A Cathy May
%T Mimic: A Fast S/370 Simulator
%J Proceedings of the ACM SIGPLAN 1987 Symposium on Interpreters and
Interpretive Techniques; SIGPLAN Notices
%C St. Paul, MN
%D June 1987
;-D on ( The SPARC hacker at home ) Pardo
Return to the
Search the comp.compilers archives again.