Hi Raphael,
>In the given excepts I cannot make out any over-/multiple allocation
>issues, everything looks good to me.
Thanks for taking the trouble to look through it.
>The fragment from stepper.asm does not match the .map file, are you
>sure the two resulted from the same build? [While writing this I
>got the idea that this might be a gplink bug, more details below.]
It is possible I get them mixed up, I've now done a clean build of
two cases that don't work and one that does and sent them
separately to you.
> So this is a largish reservation, which I guess originates from this
> (from stepper.c):
>
> stepperState t;
>
USE_STEPPER(CRITICAL(memcpy(&t,&STEPPER,sizeof(stepperState));));
>Now I wonder: Do you have multiple modules (.c files) called stepper,
>so that more than one of them allocate data in sections called
>udata_stepper_XXX, which are subsequently overlaid (incorrectly) by
>the linker?
I don't think so. Although, mind you the stepper.c does a self-include
(see the code!) but I don't see how that could cause the problem. And
in anycase the present version has that 'trick' commented out.
>You could also post the complete .map files (both working and
failing)
>tar'ed and compressed (or zipped)
Sent them to you, don't want to share all laundry here!
br Kusti
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
