Re: [cc65] o65 generation bug?

Hi Uz,

As requested, this follow-up is going directly to you and not the
mailing list.  I couldn't get gmail to attach the source files, so
I pasted them into the message.  Hope it's not a problem to paste
the text into files.

Thanks for your attention to this!
 // Agent Friday


On Sat, May 26, 2012, <uz@musoftware.de> wrote:
> >    > > 2.  Are the __segment_LOAD__ symbols supposed to still work?
> >    OK, looks like there's a problem then.  ...
>
> Greg is right here, the linker will always use $0000 as start address for
> the relocations, but the symbols are defined using the start address in
> the config file. Since the format is relocatable anyway, what is the
> reason not to use a start address of $0000?

Originally I was of the mindset that all relocatable segments would
naturally have a starting location of 0, and there would therefore
be no need to specify the start address in the executable file...
But as I started reading up on the .o65 format and looked at
examples of how things are actually done, there was ALWAYS a non-
zero start address specified.  Since the .o65 format specifies it,
I made my relocator to support nonzero start, and in hopes of
easily switching between .prg and .o65 output formats I've always
kept a start address in the .cfg.

But now I'm thinking that if .o65 files are to be written out in
"simple" format that the ideal of every segment beginning at zero
is simply not an option.

> >    I did an ld65 --dump-config lunix... all I could think to do.  Are
> >    there perhaps better starting points?
>
> The config used for modules is also available and it is simpler. The
> module target is used for drivers (tgi, mouse and serial). They use
> a jump table at the start of the code for the entry points into the
> driver.

Thanks, I'll take a look at those, but for now I think there's
adequate support for a bug report around the linker-defined segment
variables (__xxxx_LOAD__).  See below.

> ... Is there any reason not to use exactly one memory area
> with $0000 as a start address in the config file? While the linker cannot
> always generate output in "simple" format (alignment options may prevent
> that), having the segments in adjacent order starting at zero should
> always be possible. Or is this wrong?

The issue at hand is that regardless of where the first segment is
made to start, the segment start variables (__xxxx_LOAD__,
__xxxx_RUN__) are always set to 0 if .o65 output is chosen.  The
normal and recommended model of arranging  CODE, DATA, and BSS
segments contiguously in that order GUARANTEES that DATA and BSS
will have non-zero starts, but they are still defined by the
symbols to be $0000.  This is just plain wrong.  If these symbols
cannot be output with the correct value, then they are essentially
unusable and should not be generated.  The linker clearly knows
where these segments are going because it puts the correct values
in the .o65 tbase, dbase, and bbase fields.  It needs to export the
correct segment definition symbols as well.

Even the simplest .cfg will demonstate this:


==== command-line ====
>>  cl65 -t c64 -C bug.cfg bug.asm

==== bug.cfg ====
MEMORY {  RAM: start=$8000, size=$2000,type=rw;}
SEGMENTS {  CODE: load=RAM, type=ro,  define= yes;
            DATA: load=RAM, type=rw,  define= yes;
            BSS:  load=RAM, type=bss, define= yes; }
FILES { %O:  format=o65; }

==== bug.asm ====
.IMPORT __CODE_LOAD__,__CODE_RUN__
.IMPORT __DATA_LOAD__, __DATA_RUN__, __BSS_LOAD__

.CODE
        LDA     #<__DATA_RUN__
        LDX     #>__DATA_RUN__
        RTS

.DATA
BEGIN_DATA:
        .BYTE   "------>"   ; --- marker, makes data easier to find ---
        .WORD   __CODE_LOAD__,__CODE_RUN__,__DATA_LOAD__,__BSS_LOAD__
        .BYTE   "<--------" ; --- marker, makes data easier to find ---
        .WORD   BEGIN_BSS

.BSS
BEGIN_BSS:
JIFFIES_PASSED: .BYTE 0
ANI_FLAGS:      .BYTE 0


======= OUTPUT FILE =======

$0000 01 00 6F 36 35 00 00 08  ..o65...
$0008 00 80                      $8000  text start, as set in .cfg
            05 00                  $05  text size
                  05 80          $8005  data start
                        1A 00      $1A  data size
$0010 1F 80                      $801F  bss start
            02 00                  $02  bss size
                  00 00 00 00           zp start and size
$0018 00 00                             stack required
            <snip!>
$0040 30 31 32 00 00
                     A9 00              LDA #0 <-- __DATA_RUN__=$0000 ??
                           A2 00        LDX #0
$0048    60                             RTS
            2D 2D 2D 2D 2D 2D 3E  -------> (marker)
$0050    00 00                   $0000! .WORD __CODE_LOAD__
               00 00             $0000! .WORD __CODE_RUN__
                     00 00       $0000! .WORD __DATA_LOAD__
                           00 00 $0000! .WORD __BSS_LOAD__
$0058    2D 2D 2D 2D 2D 2D 2D     <------- (marker)
$0060 2D 2D
            1F 80                $801F  .WORD BEGIN_BSS
                  00 00                   (no imports)
                        02 23           fix-up for "<__DATA_RUN__"
$0068 02 43 00                          fix-up for "<__DATA_RUN__"
               00                         (end of code reloc info)
                  08 82                 fix-up for "__CODE_LOAD__"
                        02 82           fix-up for "__CODE_RUN__"
$0070 02 83                             fix-up for "__DATA_LOAD__"
            02 84                       fix-up for "__BSS_LOAD__"
                  0B 84                 fix-up for "BEGIN_BSS"
                        00                (end of data reloc info)
                           00 00          (no exports)
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.