***SPAM*** Re: [cc65] o65 generation bug?

Hi!

On 14.05.2012 12:19, Agent Friday wrote:
 > I removed the LDADDR segment from the code, and that seemed to clear up
 > the discrepancies.  (Well, almost.)  It appears that some of the
 > calculations rely on the assumption that the code segment will be the
 > first thing specified to go into the file, and if it's not so then
 > things get thrown off.

I'm not able to check that currently, but it might be true. ld65 has to 
make some limitations and assumptions about segments, because o65 is 
less flexible than the native object file format. If it is true, then it 
would of course be nice if the linker could emit a warning or an error. 
But as said before, I'm currently not able to check it, so the problem 
may have some other cause.

But sitting here in the hotel bar drinking a nice cup of coffee, I have 
another idea for you to try:

If you look at the existing config files that cause the linker to emit 
o65 files, you will notice a few differences to the one you're using. I 
would suggest that you start with a config that is as similar as 
possible to an existing one and then change it step by step. This way 
you will be able to diagnose which change in the config file is causing 
your problems.

If this doesn't help, then please send me a small(!) but compilable(!) 
example of non working code via private mail.

Regards


	Uz


>
> Instead of actually removing the .WORD __CODE_LOAD__ directive, I moved
> it into the DATA segment to see what got generated.  LD65 actually
> generated a text-relative fix-up entry in the data seg relocation table,
> which is good, but the actual value generated for __CODE_LOAD__ was
> still 0.  That seems odd.  Are the "define=yes" settings meant to be
> rendered invalid by choosing .o65 as the output format?
>
> I guess I'm left with a couple of questions now...
>
> 1.  I'd like some nice way to be able to switch between .o65 and binary
> file formats w/o having to make temporary edits to my code.  It would be
> nice if I could do this by specifying something on the command-line, but
> I haven't looked too deep into the possibilities.
>
> 2.  Are the __segment_LOAD__
>
> I prefer to handle jump tables by placing it in its own "JMPTBL"
> segment, thus being able to guarantee that the jump table is the first
> code in the target w/o relying on what order the source files are
> specified.  I tried this out, putting the segment JMPTBL first in the
> segments section, just before code, and it seemed to work nicely.  :-)
> However, __JMPTBL_LOAD__ also came up 0.
>
>


-- 
Ullrich von Bassewitz                                 uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.