• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 15 subscribers
  • Views 845 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LAST segment misplacement

Oleg Sergeev

hi,

according manual, when we need a segment to be placed at the end of specified memory we should use linker directive SEGMENTS. Well, in the field "User Segments" of LX51 Locate I have next string:

?PR?LAST(LAST)
Then next test program:
; reset vector --------------------------;
?PR?RESET	SEGMENT CODE AT 0x0000
		RSEG	?PR?RESET
		JMP	START
; timer 0 vector ------------------------;
?PR?T0INT	SEGMENT CODE AT 0x000B
		RSEG	?PR?T0INT
		JMP	T0INT

; work segment --------------------------;
?PR?TEST	SEGMENT CODE
		RSEG	?PR?TEST
START:		JMP	$
T0INT:		RETI

; last segment --------------------------;
?PR?LAST	SEGMENT CODE
		RSEG	?PR?LAST
		NOP

		END

produces next map file:
START     STOP      LENGTH    ALIGN  RELOC    MEMORY CLASS   SEGMENT NAME
=========================================================================
* * * * * * * * * * *   C O D E   M E M O R Y   * * * * * * * * * * * * *
000000H   000002H   000003H   BYTE   AT..     CODE           ?PR?RESET
000003H   000005H   000003H   BYTE   UNIT     CODE           ?PR?TEST
000006H   000006H   000001H   BYTE   UNIT     CODE           ?PR?LAST
000007H   00000AH   000004H   ---    ---      **GAP**
00000BH   00000DH   000003H   BYTE   AT..     CODE           ?PR?T0INT
And this is wrong because last segment named ?PR?LAST is not last one in the code space area.
But when I use next test program:
; reset vector --------------------------;
?PR?RESET	SEGMENT CODE AT 0x0000
		RSEG	?PR?RESET
		JMP	START
; timer 0 vector ------------------------;
		ORG	0x000B
		JMP	T0INT

; work segment --------------------------;
?PR?TEST	SEGMENT CODE
		RSEG	?PR?TEST

START:		JMP	$
T0INT:		RETI

; last segment --------------------------;
?PR?LAST	SEGMENT CODE
		RSEG	?PR?LAST
		NOP

		END
the MAP file shows correct results:
START     STOP      LENGTH    ALIGN  RELOC    MEMORY CLASS   SEGMENT NAME
=========================================================================
* * * * * * * * * * *   C O D E   M E M O R Y   * * * * * * * * * * * * *
000000H   00000DH   00000EH   BYTE   AT..     CODE           ?PR?RESET
00000EH   000010H   000003H   BYTE   UNIT     CODE           ?PR?TEST
000011H   000011H   000001H   BYTE   UNIT     CODE           ?PR?LAST

The only difference I see is that in the first case there is code gap in which linker has placed the last segment. Is there a way to avoid such behaviour?

Thanks,
Oleg

Parents
  • 0

    It could be documented a bit more exactly, but I don't agree this counts as a "misplacement" of the segment. It's quite reasonable that absolutely positioned segments are ignored when handling the LAST option. If it wasn't, the linker might well end up putting such a LAST segment beyond the end of memory, just because you put an absolute one that touches the ceiling.

    There used to be (still is?) a real bug with LAST, though: if there's a gap in the middle of the sequence of relocatable segments (e.g. caused by the RESERVE directive), a LAST segment that fits there, could end up before the gap, even though there's more code located after it. We came across this when we RESERVEd some bytes close to the 64K boundaries of a DS390 to avoid hitting one of its errata. We ended up having to enlarge our LAST segment so it would no longer fit in the gap.

    This IMHO made (makes?) LAST unusable for the main job it would appear to be meant for: defining a "code ends here" position for purposes of checksumming.

Reply
  • 0

    It could be documented a bit more exactly, but I don't agree this counts as a "misplacement" of the segment. It's quite reasonable that absolutely positioned segments are ignored when handling the LAST option. If it wasn't, the linker might well end up putting such a LAST segment beyond the end of memory, just because you put an absolute one that touches the ceiling.

    There used to be (still is?) a real bug with LAST, though: if there's a gap in the middle of the sequence of relocatable segments (e.g. caused by the RESERVE directive), a LAST segment that fits there, could end up before the gap, even though there's more code located after it. We came across this when we RESERVEd some bytes close to the 64K boundaries of a DS390 to avoid hitting one of its errata. We ended up having to enlarge our LAST segment so it would no longer fit in the gap.

    This IMHO made (makes?) LAST unusable for the main job it would appear to be meant for: defining a "code ends here" position for purposes of checksumming.

Children