> David, > > I while ago I submitted a patch to binutils with which you can create an assembler file with symbols defined. > msp430-objcopy -O msp430asm [infile] [outfile] > (Can't remember who sent it to me) > > Then you can upload outfile to msp430 and debug it with win tools. >
Thanks for that pointer - I hadn't noticed it. msp430-objcopy produces a bare hex dump of the code section, followed by a list of the symbols. This would let me get the addresses of variables for the watch window, but the code window has much less information. Maybe I can cut-and-paste the symbols from the objcopy output into the assembly + comments from the objdump output and get the best of both worlds. Once the electronics guy here has got my card ready, I'll give it a shot and see what gives me the best results (and maybe the program will work first time, so I won't need to do any debugging :-) mvh. David > ~d > > > On Tue, 9 Jul 2002 13:28:31 +0200 > "David Brown" <[email protected]> wrote: > > > Hi Steven, > > > > I've now build binutils with your patch (as applied by Dmitry), and I am > > generating IAR-compatible assembly code with it, which I can then assemble > > and link with IAR's tools. However, there are a few changes that would make > > it very much more useful for debugging, if they are possible (I don't know > > enough details of how objdump works, or what information is contained in the > > object files, to be able to see if this is possible or not). > > > > The first thing would be symbolic information about variables in the data > > section. When I run objdump on the final elf file, all variables are > > allocated, so all references in the assembly to variables gives their > > allocated absolute address. Would it be possible to keep symbolic > > information at this stage? I guess that means that IAR's linker would then > > allocate the final addresses for the variables, but it would make debugging > > much easier as you can then "watch" variables (although C-Spy does make this > > awkward for assembler variables - if you have a variable "unsigned int foo", > > you need to watch "*(unsigned int*) # foo" ). > > > > The other thing that would make a big difference would be to be able to > > disassemble individual object files before linking - again, this would need > > more symbolic information in these files (at the moment, running objdump on > > an object file makes all variables accessed as absolute address 0). > > > > Would something like this be possible? Or would it make more sense to patch > > gcc to produce iar assembly rather than gas assembly? Or maybe write a > > post-processor that converts gas syntax to iar syntax? I could probably do > > this last option myself, someday when I get the time (although probably by > > then TI will have finished their jtag spec's and we'll all be using gdb > > anyway...) > > > > mvh. > > > > David Brown > > Norway > > > > > > > > > Hi all, > > > > > > Attached is a patch to the MSP430 Binutils, that adds a disassembler > > > option "IAR". This allows the output of objdump to be assembled in the > > > IAR environment and debugged with the FET Tool. (You can mix assembly > > > and C code output with the disassembler). It basically reformats the > > > disassembly so that the IAR assembler can cope with it, adds labels and > > > org statements, and comments out anything that is not for the > > > assembler. > > > > > > I Suggest building the tools and installing them. Then applying this > > > patch to binutils. Then rebuilding binutils and manually copying > > > objdump over the original objdump. Im not sure if this patch interferes > > > with anything else in binutils, I think it doesn't, but I haven't tested > > > it. I dont know if the patch works under windows, I have only tested it > > > under Linux. > > > > > > Use it thus: > > > > > > msp430-objdump -DSt --disassembler-options=IAR [objfile] > > > > > > to get the disassembly, with source code interleaved. > > > > > > Regards, > > > Steven Johnson > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Stuff, things, and much much more. > > http://thinkgeek.com/sf > > _______________________________________________ > > Mspgcc-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > > > /******************************************************************** > ("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ > `6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys > (_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44 > _..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia > (il),-'' (li),' ((!.-' +7 (812) 3468202, 5585314 > ********************************************************************/ > >
