"ljp" <spamtrap@[EMAIL PROTECTED]
> wrote in message
news:909ff863-ad25-4534-930f-281c84fd9df6@[EMAIL PROTECTED]
> Alternately, does anyone know of a way to "link" assembly files, e.g.,
> if the normal order of things is:
>
> foo.s -> ASSEMBLER -> foo.o
> bar.s -> ASSEMBLER -> bar.o
> foo.o, bar.o -> LINKER -> foobar.exe
>
> then I want to get foobar.s such that
>
> foo.s, bar.s -> ??? -> foobar.s
> foobar.s -> ASSEMBLER -> foobar.exe
>
Is there some reason you can't put the source for foo and bar together
using
an editor?
(Evenbit mentioned this in the alt.lang.asm thread and Frank implied it
here.)
> The reason I'm considering this is that I need a single assembly file
> representing the program /after/ linking.
Two threads later (other is on alt.lang.asm), I'm still unsure as to /why/
do you /need/ the linked code, object header (e.g.,ELF) , etc. as
assembly...?
Are you trying to eliminate the linker during compilation?
Are you trying to transfer the application to another platform which has
no
linker?
Are you trying to get or understand the header code for the object format?
Do you need some "mystery" process (the one between the complete
disassembly
and reassembly) to be automated?
E.g., automatic instruction insertion for instruction testing... which
would be easier by writing the instruction to a buffer padded with nop's
and
a ret and then calling the instruction.
"reassembly unambiguously" (as Alex mentions) isn't an easy task on x86.
Binary encoding of instructions don't correspond 1:1 to assembly. I
recently did binary equivalent ****ts of two small FORTH interpreters from
MASM to NASM. By "binary equivalent ****ts," I mean that the instructions
are either 1) identical binary encoding or 2) same instruction with same
instruction length but different binary encoding. I haven't been able to
post them yet since NASM uses different binary encodings than MASM for
some
instructions. I.e., I've got lots and lots of instructions to disassemble
to ensure the correctness of the ****ts.
Terje brought up the issue of size. If it's really trivial, you can use a
binary editor to insert a binary patch. If it's slightly larger, you
might
hex dump the program. hex dump the patch. edit together. undump hex. I
use my own programs to do this. If it's even larger, you can split and
unsplit the files then hex... If it's really large, you can disassemble
and
reassemble while manually reworking until entire program until it matches
both the binary and the source for the objects. Having the source for the
objects should dramatically reduce the amount of work. I.e., you can tell
where each one is in the binary even from an incomplete or partially
incorrect disassembly.
Rod Pemberton
|
