Excellent; thank you. With this help I've determined that the msp430 patches to gcc don't enable the check for dwarf2 support on that architecture; as a result the compiler won't generate the line information required for integrated listings. This is probably why another user has complained that gdb can't find file locations.
I've verified that a patch to gcc's configure script changes the configuration so the proper symbols are defined. I'll do additional testing, see if there are other features that aren't being supported because of a similar problem, and get it into the mspgcc4 git repository and push the patch upstream to the primary mspgcc4 maintainers for release. It should be available for builds from the git repository by Friday morning; I can't speak to when it'll be available in svn or as pre-built packages. Peter On Thu, Jul 1, 2010 at 7:11 AM, Hans Nieuwenhuis <vz...@xs4all.nl> wrote: > I noticed the missing C source in mspgcc4 too a while ago. There is a > difference between mspgcc3 and mspgcc4 in this area. But it could also > be the underlying binutils which cause this behaviour. > Just tried to compile an ordinary X86 program using GCC 4.4.3 on Ubuntu > with these options: > > CFLAGS += -Wa,-adhlns=$(subst $(suffix $<),.lst,$<) > > This one gives me listing with C source mixed. It looks like a mspgcc > issue. Mspgcc4 has an additional -Xassembler <arg> option, but that one > has the same behaviour. > > Regards, > > Hans > > On Thu, 1 Jul 2010 12:42:24 +0200 > "JMGross" <msp...@grossibaer.de> wrote: > > > > > > > I too use objdump to generate a complete project listing from the elf > file. > > It has, however, some serious drawbacks. Not only that jumps and calls > > are not printed with their symbolic name, also the source code in the > listing > > is sometimes (often) from a completely different file or from different > > lines of the same file. So it is virtually useless. > > I guess the problem is related to the fact that I do not compile into > > the source folder (but into a /bin subdir) and also compile code from a > > common folder. > > > > The .lst ifles directly generated by the compiler with the option > > -Wa,-ahlms=$(addprefix $(OBJDIR)/,$(notdir $(<:.c=.lst))) > > is fine. Of course the compiler knows the correct source :) > > Yet I use mspgcc 3, not 4. > > > > JMGross > > > > > > On 2010-06-30, Diane Gagne <drose.ga...@gmail.com> wrote: > > > > I am in the process of moving from mspgcc 3.2.3 to mspgcc4, but I am > having > > trouble with the creation of the .lst files. When my source is compiled > > with the 3.2.3 the list files have the C code printed in them along with > the > > assembly. Using the same makefile, and compiling with the mspgcc4 the C > > code goes away which makes it harder to read. > > > > I realize that objdump will give me close to what I am looking for, but > > those files do not have the jumps listed. > > > > Is there a way to get the C code back, maybe a default option changed > that I > > do not realize? > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Sprint > > What will you do first with EVO, the first 4G phone? > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > _______________________________________________ > > Mspgcc-users mailing list > > Mspgcc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Mspgcc-users mailing list > Mspgcc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mspgcc-users >
