Mail Archives: djgpp/1993/05/19/01:57:49
I'm cross-compiling to go32 from Unix (NeXT), using gcc, GNU binutils
and the GNU assembler. The setup works well.
GNU ld lets you say "-Ttext 400000" to relocate the text segment up
to 0x400000. "nm" from the Unix side of things is happy with this,
and shows all of the symbol addresses adjusted upwards by 4
megabytes. [Interestingly, the "ld" shipped with djgpp won't allow
this relocation, complaining that the address is not a multiple of
the page size (!), and the djgpp nm doesn't understand the relocated
a.out generated from the Unix side.]
When I try to go32 the a.out with the relocated text segment under
go32, the program *immediately* crashes with the PC at the location
where I placed the text segment (in this case, 0x400000). Even int
main(){return 0;} dies.
Perhaps those of you using the Sparc cross-compilation tools (just
announced on this list) can generate the same problem.
DJ modified the a.out format. Usually a.out files contain the exec
header structure only in the first page. The remaining bytes are
filled with \0s. go32 a.out format starts the code immediately after
the exec strucuture (offset 0x20). Your utilites must be generate go32
a.out files. The Sparc cross-compilation tools are created in that
way. Usually the standard nm tool will not work. You need a cross
version. Try to rebuild the binutils using the following configure
parameters for the target. This will setup your system for go32
emulation by default.
./configure sparc -target=i386-go32
For what it's worth, I need to end up with addresses 0-0x3FFFFF
read/writable by my program, with the text/data/bss segments
relocated anywhere above this area.
Go32 doesn't use the info from the a.out file to setup its segments
permissions. All the address space is R/W because the data segment
covers all of it, it is also executable as the code segment covers all
of it also.
Regards,
Rami
- Raw text -