www.digitalmars.com         C & C++   DMDScript  

c++.dos - optlink segment ordering problem

reply Japheth <mail japheth.de> writes:
Hello,

I have a binary which needs a special segment ordering:

_TEXT    16bit DGROUP
_DATA    16bit DGROUP
_TEXT32  32bit

Although I used linker option /NOREO the _TEXT32 segment is always grouped 
*before* DGROUP. How could this be avoided? (there is no module with the 
"DOSSEG" directive included).

Regards

Japheth
Mar 24 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Japheth wrote:

 I have a binary which needs a special segment ordering:
 
 _TEXT    16bit DGROUP
 _DATA    16bit DGROUP
 _TEXT32  32bit
 
 Although I used linker option /NOREO the _TEXT32 segment is always 
 grouped *before* DGROUP. How could this be avoided? (there is no module 
 with the "DOSSEG" directive included).
Put the object file with the ordering in it you wish first on the command line to the linker.
Mar 29 2006
parent reply Japheth <mail japheth.de> writes:
 Put the object file with the ordering in it you wish first on the 
 command line to the linker.
Thanks, but I did this already of course, with no success. The first module is written in assembly: _DATA segment dword use16 public 'CODE' _DATA ends _TEXT segment byte use16 public 'CODE' _TEXT ends _TEXT32 segment dword use32 public 'CODE' _TEXT32 ends DGROUP group _DATA, _TEXT CGROUP32 group _TEXT32 So I really would expect _TEXT32 to be "behind" DGROUP, but OPTLINK puts it before DGROUP. Using MS OMF linker and tlink _TEXT32 is behind DGROUP, but they have some problems with 32bit object modules. Regards Japheth
Mar 29 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Japheth wrote:

 The first module is written in assembly:
 
 _DATA   segment dword use16 public 'CODE'
 _DATA    ends
 _TEXT    segment byte use16 public 'CODE'
 _TEXT    ends
 _TEXT32    segment dword use32 public 'CODE'
 _TEXT32    ends
 
 DGROUP  group _DATA, _TEXT
 CGROUP32 group _TEXT32
 
 So I really would expect _TEXT32 to be "behind" DGROUP, but OPTLINK puts 
 it before DGROUP. Using MS OMF linker and tlink _TEXT32 is behind 
 DGROUP, but they have some problems with 32bit object modules.
Try making _TEXT32 the last member of DGROUP.
Mar 30 2006
parent reply Japheth <mail japheth.de> writes:
 Try making _TEXT32 the last member of DGROUP.
Thanks, but this is no valid option because - the 32bit segment must not be in DGROUP, because it is moved to extended memory once it has been loaded by the DOS loader. That's the reason why I want it to be the last segment in the binary. - the assembler (MASM) complains about changing segment attributes. It has the strong opinion that one cannot mix 16bit and 32bit segments in a group. Is the /NOREO option not functional/not implemented? Regards Japheth
Mar 30 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Japheth wrote:
 
 Try making _TEXT32 the last member of DGROUP.
Thanks, but this is no valid option because - the 32bit segment must not be in DGROUP, because it is moved to extended memory once it has been loaded by the DOS loader. That's the reason why I want it to be the last segment in the binary.
Why not just use the supported 32 bit DOS extender?
 - the assembler (MASM) complains about changing segment attributes. It 
 has the strong opinion that one cannot mix 16bit and 32bit segments in a 
 group.
This should not be a problem, as all the segments should be marked in the assembler source as 32 bits.
 Is the /NOREO option not functional/not implemented?
I don't know. I didn't write the linker. I'm loathe to change how it works, though, because it may break a lot of existing code.
Mar 31 2006
parent reply Japheth <mail japheth.de> writes:
 Why not just use the supported 32 bit DOS extender?
Well, the binary *is* a dpmi host, so it cannot use another DOS extender's host.
 This should not be a problem, as all the segments should be marked in 
 the assembler source as 32 bits.
but the example 4 lines above show that _DATA and _TEXT are (and must be) 16bit.
 I don't know. I didn't write the linker. I'm loathe to change how it 
 works, though, because it may break a lot of existing code.
Thanks anyway!
Mar 31 2006
parent Walter Bright <newshound digitalmars.com> writes:
Japheth wrote:

 Thanks anyway!
You can also try just concatenating the 16 and 32 bit sections built in separate files.
Mar 31 2006