Fixups with >64k segments 
Author Message
 Fixups with >64k segments

i have a couple questions about how linkers deal with fixups and offsets
that are greater than 64k.  take this small tasm program:

;MODULE1.ASM
.386p
nosmart

group perty code3,code2

code2 segment byte private use32 'blah'
 db NUMBYTES dup (0)
code2 ends

code3 segment word public use32 'blah'
 db 2000 dup (6)
 shocker label DWORD
code3 ends

assume cs:_code
_code segment para private use16 'code'
main:

lea bx,perty:[SMALL shocker]
lea cx,perty:[LARGE shocker]

_code ends
end main

if NUMBYTES is >=65535, ALINK and QLINK understandably give a fixup
overflow for the first LEA (M$ LINK also has difficulties with the
second one, don't understand why..)  but if NUMBYTES=64000, there are no
fixup problems with any of the 3 linkers; the offset is just
quietly squashed to 16-bit, even though 64000+2000 also exceeds 64k.
what in the fixup process causes this behavior?

and a slightly different question.  if the 'code2' segment is removed
completely from MODULE1 (above code) and there is also a MODULE2.ASM:

.386
perty group code3

code3 segment word use32 public 'blah'
 db 65538 dup (5)
code3 ends

end

linking MODULE2 MODULE1 won't cause any fixup errors here, but they will
 occur if code3 in MODULE2 is changed to private (or renamed).  now
the same numbers are still being added to determine the final offset
of 'shocker', so i'm not sure why fixup errors would occur in one case
and not the other.  (btw, TLINK does no whining in any of these
examples)

thanks


Sent via Deja.com http://www.*-*-*.com/
Share what you know. Learn what you don't.



Sun, 23 Dec 2001 03:00:00 GMT  
 Fixups with >64k segments

Quote:

> i have a couple questions about how linkers deal with fixups and offsets
> that are greater than 64k.

  The decision of whether a fixup is an overflow or not is rather
complicated.  The OMF format does not give the assembler enough
flexibility to really communicate the requirements to the linker.
The OMF format documentation also does not make clear the rules
for a linker to decide overflow vs nonoverflow cases.

  Consider  [symbol-0x7000] vs. [symbol+0x9000].  One of those
might be an overflow and the other not;  But the OMF specification
(16-bit form) does not let the assembler tell the linker which
is meant.

Quote:
> code2 segment byte private use32 'blah'
>  db NUMBYTES dup (0)
> code2 ends

> code3 segment word public use32 'blah'
>  db 2000 dup (6)
>  shocker label DWORD
> code3 ends
> lea bx,perty:[SMALL shocker]
> if NUMBYTES is >=65535, ALINK and QLINK understandably give a fixup
> overflow for the first LEA (M$ LINK also has difficulties with the
> second one, don't understand why..)  but if NUMBYTES=64000, there are no
> fixup problems with any of the 3 linkers; the offset is just
> quietly squashed to 16-bit, even though 64000+2000 also exceeds 64k.
> what in the fixup process causes this behavior?

  The part of the offset (the 2000) that is known by the assembler
can be encoded in the .OBJ file in one of two ways.  One method
results in a slightly smaller .OBJ file and tells the linker not
to consider that part of the offset in its overflow check.  The
other method takes more OBJ space and tells the linker to consider
that part of the offset.  I don't know any assemblers that are
intelligent about deciding which form to use based on getting the
overflow check to be correct.  I guess your assembler just picks
the smaller form.

Quote:
> and a slightly different question.  if the 'code2' segment is removed
> completely from MODULE1 (above code) and there is also a MODULE2.ASM:
> code3 segment word use32 public 'blah'
>  db 65538 dup (5)
> code3 ends

> end

> linking MODULE2 MODULE1 won't cause any fixup errors here, but they will
>  occur if code3 in MODULE2 is changed to private (or renamed).

  That one is strange.  Have you generated a map file and checked
which order the segments occur in?
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/


Sun, 23 Dec 2001 03:00:00 GMT  
 Fixups with >64k segments

Quote:


> > i have a couple questions about how linkers deal with fixups and
offsets
> > that are greater than 64k.

>   The decision of whether a fixup is an overflow or not is rather
> complicated.  The OMF format does not give the assembler enough
> flexibility to really communicate the requirements to the linker.
> The OMF format documentation also does not make clear the rules
> for a linker to decide overflow vs nonoverflow cases.

>   Consider  [symbol-0x7000] vs. [symbol+0x9000].  One of those
> might be an overflow and the other not;  But the OMF specification
> (16-bit form) does not let the assembler tell the linker which
> is meant.

ahh.. interesting.

thanks for the reply.

- Show quoted text -

Quote:
> > code2 segment byte private use32 'blah'
> >  db NUMBYTES dup (0)
> > code2 ends

> > code3 segment word public use32 'blah'
> >  db 2000 dup (6)
> >  shocker label DWORD
> > code3 ends

> > lea bx,perty:[SMALL shocker]

> > if NUMBYTES is >=65535, ALINK and QLINK understandably give a fixup
> > overflow for the first LEA (M$ LINK also has difficulties with the
> > second one, don't understand why..)  but if NUMBYTES=64000, there
are no
> > fixup problems with any of the 3 linkers; the offset is just
> > quietly squashed to 16-bit, even though 64000+2000 also exceeds 64k.
> > what in the fixup process causes this behavior?

>   The part of the offset (the 2000) that is known by the assembler
> can be encoded in the .OBJ file in one of two ways.  One method
> results in a slightly smaller .OBJ file and tells the linker not
> to consider that part of the offset in its overflow check.  The
> other method takes more OBJ space and tells the linker to consider
> that part of the offset.  I don't know any assemblers that are
> intelligent about deciding which form to use based on getting the
> overflow check to be correct.  I guess your assembler just picks
> the smaller form.

thanks for the explanation.  hmm.. do you know what field in the OBJ
file would deal with this?  i looked at the specification, but it's
above me...

- Show quoted text -

Quote:
> > and a slightly different question.  if the 'code2' segment is
removed
> > completely from MODULE1 (above code) and there is also a
MODULE2.ASM:

> > code3 segment word use32 public 'blah'
> >  db 65538 dup (5)
> > code3 ends

> > end

> > linking MODULE2 MODULE1 won't cause any fixup errors here, but they
will
> >  occur if code3 in MODULE2 is changed to private (or renamed).

>   That one is strange.  Have you generated a map file and checked
> which order the segments occur in?

yep.  the segments occur in the intended order.  if the code causing
the fixup overflow is removed, the EXEs produced by QLINK and MS Link
with MODULE2's code3 being private will be identical to those when it's
public.  strange indeed..

also, why would m$ link be {*filter*} on the "LEA .. [LARGE offset]"
fixups?  if it handles 32-bit (non 'CODE') segments, then wouldn't
32-bit fixups be a logical thing to expect?


Sent via Deja.com http://www.*-*-*.com/
Share what you know. Learn what you don't.



Tue, 25 Dec 2001 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. -=- Getting Fixups into Your Data Segment ??? -=-

2. -=- Getting Fixups into Your Data Segment ??? -=-

3. Group or Segment Class Exceeds 64k

4. Scanning a whole 64k segment

5. ERROR segment text exceeds 64K

6. breaking the 64K data segment

7. Help: gp-relative segments together exceed 64k bytes

8. Segment Sizes larger than 64K?

9. Segment Size Exceeds 64K

10. Another problem with the 64K boundary on data segments

11. code segment exceeds 64K

12. 64K limit for data segments

 

 
Powered by phpBB® Forum Software