Menu
▾
▴
[sdcc-devel] [ sdcc-Bugs-3373359 ] HEX files generated on 64bit host system do not work
|
From: SourceForge.net <no...@so...> - 2011-09-16 09:26:31
|
Bugs item #3373359, was opened at 2011-07-21 11:01 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3373359&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pic14 target >Group: non bugs >Status: Closed >Resolution: Rejected >Priority: 5 Private: No Submitted By: Morpheus (smorpheus) >Assigned to: Maarten Brock (maartenbrock) Summary: HEX files generated on 64bit host system do not work Initial Comment: Hi, I have a big problem since years: I started using sdcc-2.9.0 for PIC16F88 and recently moved to sdcc-3.0.0 and with both versions I still can not compile hex files on any 64bit linux host. The same .c source file compiled on a 32bit system produces a good hex file that can be loaded on my pic, while compiling it on a 64bit system it gives a different hex file, that picprog refuses to burn since it believes it has been created for a different target. The command I use are: sdcc-2.9.0 -mpic14 -p16f88 -V source.c sdcc-3.0.0 --use-non-free -mpic14 -p16f88 -V source.c I find quite strange that nobody has faced this before! (at least I cannot find anything related to my problem on the web). Ciao, Luca ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2011-09-16 11:26 Message: Since SDCC creates identical .asm files the problem must lie with gputils. ---------------------------------------------------------------------- Comment By: Morpheus (smorpheus) Date: 2011-07-21 14:13 Message: I did not realize that sdcc calls gpasm and gplink from another package. I was experimenting using different sdcc (2.9.0 and 3.0.0) binaries (from debian 32bit pagkage, from debian 64bit pagkage, my own compiled on 32bit system and my own compiled on 64bit system) and in none of the listed situation I was able to produce a good .hex on my 64bit system. Now I am starting to understand better: the .asm generated on 32 and 64 bit system are almost identical (they differ only in some comments like: diff frequenzimetro64.asm frequenzimetro32.asm 3,4c3,4 < ; Version 2.9.0 #5416 (Jan 10 2010) (UNIX) < ; This file was generated Thu Jul 21 14:05:20 2011 --- > ; Version 2.9.0 #5416 (Sep 2 2010) (UNIX) > ; This file was generated Thu Jul 21 14:05:35 2011 2047c2047 < ;genSkipc:3083: created from rifx:0x7fff2539b600 --- > ;genSkipc:3083: created from rifx:0xbf8b53c0 2132c2132 < ;genSkipc:3083: created from rifx:0x7fff2539b600 Except from comments all the instruction are identical, so if I understand correctly the bug seems to be in the gputils package? ps:sorry for not understanding from the beginning... ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2011-07-21 13:45 Message: Oh, I forgot to ask: Do you use the same sdcc binary on the 32-bit and 64-bit host? Do/did you compile them yourself or do you use (our) precompiled binaries? ---------------------------------------------------------------------- Comment By: Raphael Neider (tecodev) Date: 2011-07-21 13:36 Message: Since gputils is also involved in creating a .hex-file (assembler, linker) and since you seem to have both a 32-bit and a 64-bit setup ready, could you please upload the respective .asm files as generated by sdcc as well? If they differ significantly, sdcc/pic14 is probably broken and the error should be traceable from the .asm output. If the .asm files match, you might have to ask for help with the gputils project. Thank you for the report. Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3373359&group_id=599 |