On Mon, 2006-04-03 at 12:44 -0500, David Kelly wrote: > Vincent, thats originally my Makefile and object.list should already > contain exactly what you are looking for.
Hi David ! Yes, I still use your Makefile, I quite like it :-) It makes it very easy to add more files to my project, and generates all the files I might need... > Change the above to -DS. I've built your sources and verified. Don't > know when the "S" disappeared as its still in my version. I removed it today to see if it would make any difference, since someone suggested this flag on the list. I also tried -S and notice a big improvement over -DS, in that, with -S, the bags of strings I have defined, appear like this : 0000009c <menu_main>: 9c: 05 5f 5f 5f 5f 5f 5f 5f 20 4d 61 69 6e 20 5f 5f ._______ Main __ ac: 5f 5f 5f 5f 5f 00 45 72 72 6f 72 20 63 6f 64 65 _____.Error code bc: 73 20 20 20 20 20 20 20 00 00 00 91 02 50 61 72 s .....Par ................... ................... instead of miles of meaningless assembly "instructions". It makes much more sense, more useful, and is also a lot more compact if nothing else... With regard to the C/assembly mix problem though, it doesn't change a thing it seems (no better no worse), so I might as well keep using -S instead of -DS, unless something important escaped me of course. > Speaking of having built your sources, 3.4.6 complains on "gmake > depend": > > In file included from ui.h:11, > from menu.h:7, > from main.c:14: > /usr/local/lib/gcc/avr/3.4.6/../../../../avr/include/avr/eeprom.h: > 172:3: #error "No write enable bit known for this device's EEPROM." Hmmm, I have 3.4.3 and it doesn't complain about this... though it does complain about many other things !! ;-) but it compiles anyway. >OK, I spoke too soon. For example ui_message_show source is totally >separate from its disassembly listing. Get lots of warnings like this: >ui.c:762: warning: passing arg 1 of `eeprom_read_byte' makes pointer >from integer without a cast Ah yes, I remember trying to get rid of these specific warnings, but I didn't see the problem, as I was using the exact syntax found in avr-libc's documentation. I think I fixed it with some type casts, but that made the eeprom_read_byte() very difficult to read :-( The documentation says that the address can be passed as a simple integer, but gcc is less arranging and wants a pointer not an integer... Well, I will fix it again and see if that improves the output of objdump... >...which might contribut to avr-gcc getting confused and not properly > tagging source with code. Hmmm, thanks. Makes sense indeed. objdump can only do as good as the elf gcc passes on to it... I will try fixing all my warnings then. The problem is that I think some of them I never managed to fix, like: menu.c:53: warning: initialization from incompatible pointer type menu.c:67: warning: initialization discards qualifiers from pointer target type Regards, -- Vince _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list