Cc65: ld65: Multiple Defects with Overwrite

[TheRealQuantam]

Overwrite mode does not work properly, with two problems.

1. With start=x, the file offset is not computed correctly. In cc65/src/ld65/bin.c line 198, the memory's base address is subtracted from the start address to get the memory offset, but the memory's base file offset is not subsequently added before fseeking.
2. When an overwrite occurs in the non-last memory, ld65 performs the overwrites between writing the relevant memory and the subsequent memory. When performing the overwrite, it seeks to where the overwrite should occur (which is wrong due to #1) and writes the overwrite. Then when it moves on to write the following memory it tries to write it immediately after, without ever seeking back to the end of the file, resulting in an internal error because the actual file offset is not the expected file offset (thrown at line 144).

A config file that exposes these bugs:

1. The overwrites occur in the $2000-$4000 file offset range, which is not at all where it should be
2. When it tries to write CHR00 it throws "ld65: Internal Error: Invalid file offset for memory area CHR00: 9862/255638"
   bmq.cfg.txt

EDIT: While working on a local kludge to fix the problem, I found the problem runs deeper than just those above. ld65 actually does not even correctly calculate subsequent segment file offsets when there's an overwrite segment in ProcessCfg, before it even gets to BinWriteMem.

[oliverschmidt]

@laubzega: It would be great if your could comment on this issue...

[laubzega]

@TheRealQuantam: Hey, thanks for giving this code some exercise. ;) Can you tell me whether you can still trigger #2 if you change said line 198 to:

fseek (D->F, NewAddr - M->Start + M->FileOffs, SEEK_SET);

I have been playing with a (somewhat simplified) version of your config file, and cannot replicate it once the line above is fixed. Also, can you elaborate on the problem with CfgProcess()? Is this about the issue mentioned in the documentation ("OVERWRITE segments should be the final segments loaded to a particular memory area") or about something else?

[TheRealQuantam]

I had to make that and 2 others to fix my issues when I first commented. I would have submitted it as a pull request, but I'm really not that familiar with the codebase and I didn't know if the fixes I made were the best way to do it or break anything I don't use.
ld65.diff.txt

[oliverschmidt]

@laubzega: It seems there are fixes "available". Can you please provide a pull request?

[laubzega]

Hi Oliver,

I've put it on my to-do list for this weekend.

Br,
Milek

On Tue, May 19, 2020, 2:42 PM Oliver Schmidt [e-mail]
wrote:

@laubzega https://github.com/laubzega: It seems there are fixes
"available". Can you please provide a pull request?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cc65/cc65/issues/928#issuecomment-631099040, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABIAQS7UO5H4U2KPRDF5H3LRSL4M3ANCNFSM4IOFRZXA
.

[oliverschmidt]

Hi Milek,

Thanks for quick reply and the positive feedback :-)

Hoping for bad weather on the WE ;-),
Oliver

[laubzega]

We're having a heat wave, not sure if it qualifies as bad weather tho. ;)

[oliverschmidt]

May I ask we you are - roughly - located?

[laubzega]

Santa Clara, California.

[oliverschmidt]

<jealous>Too bad ;-)</jealous>

[oliverschmidt]

Thanks for taking care of this issue!