On May 03, 2009; 01:44am, Xiaofan Chen wrote:

> I would solve the problems in a different way. Now you have serveral
> unknowns. Your program may be wrong, your hacked compiler may
> be wrong. So you want to remove one unknown first.
>
> For example, you can try the original V3.12 compiler (under Linux with Wine
> or under Windows) and see if that works. If it works with your program,
> then you know your modification is not correct. If it does not work with
> the known-good compiler, then debug your program until it works.
> After that, try your own compiler. 

Xiaofan,

Thanks for the suggestions; I had aleady seen all of your links though - I did
wonder if you were the same Xiaofan !

As for your other suggestion, I have compiled blink.c via the same commands
under Windows, using the C30 eval version from Microchip, and it compiles/links
fine.  However, I am struggling to reconcile this result with the changes I
have made to the packages in order to get it to work on my Ubuntu installation.

I did not have to change any source files (in binutils, gcc or pic30-support),
only the Debian template build scripts and the path names in a few header files
(v3.12 has path names in a c30_flag_definitions.h header, so the changes are
very localised).

After putting some debug printf's in the binutils linker, I have discovered
that the problem is PC-relative relocations, or at least that's a symptom
that is manifesting itself and ultimately stopping the linker.  For some
reason, the linker is performing some right-shifts and causing back-references
(negative PC offsets) to turn into very large numbers.  These very large
numbers are then seen as addresses outside of the PIC's range.  It's almost as
if it should be shifting using the sign bit rather than zeroes - that would
make sense.  Alas, I'm not an expert with binutils, so I'd rather not try and
change any behaviour for fear of producing broken object code - that would be
even worse to troubleshoot.  Microchip have added some extra checks since the
last version of the source (to prevent segfaults), but they have not changed
the relocation logic itself.

I initially tried to use v3.01, which you and others have reported as working
under Ubuntu, but I get segfaults during the build process, which is why I
thought it better to try using a newer version.  I am running a 64-bit AMD
Turion, so I wonder if that could be the cause at all ?

I tend not to use Windows very often, so I would like to get this working if
possible - do you think Microchip would be interested in a dialogue or have I
got no chance ?  I doubt the binutils maintainers would help either since
they're Microchip enhancements and not core binutils.

Any suggestions on how to progress would be appreciated.

Regards,

Pete Restall
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist