just send me a patch, David. ~d
On Wed, 10 Jul 2002 21:47:30 +0200 "David Brown" <[email protected]> wrote: > > Hi, > > > > I'm using msp430-objdump with the IAR disassembler option to generate an > IAR > > assembly file from my linked elf file. I can then re-assembler and > re-link > > it using IAR's tools. However, the .data section is causing me trouble. > If > > I use "-dST" for the objdump, then the .data section is missing, which > means > > that any initialised data gets 0xff (i.e., blank flash) as its contents. > If > > I use "-DST", then the .data section is included (it is disassembled, > which > > looks a bit odd, but the data is correct), but the section address is the > > VMA of the section (0x0200), not the LMA (0xe768, in my case). What I > need > > is a way to get the .data section out of the elf file, preferably along > with > > the rest of the disassembly, but with the origin set to the LMA rather > than > > the VMA. Does anyone know if there is a way to do this? > > > > Many thanks, > > > > David Brown > > Norway. > > > > I have now fixed the situation, by making some changes to objdump.c . The > three changes I had to make were making the label use the lma rather than > vma (about line 1936); > objdump_print_IAR_label(abfd, section, sym,section->vma + > addr_offset, > &disasm_info, false); > to > objdump_print_IAR_label(abfd, section, sym,section->lma + > addr_offset, > &disasm_info, false); > > I also had to make the -dST flag include the .data section, because -DST was > causing the .vectors section to be strangely generated. This meant adding a > line > && (section->flags & SEC_DATA) == 0 > at line 1827, where the disassemble_data() function determines whether or > not to print the section. > > Finally, I had to comment out the lines to add +0x... strings to the labels > in objdump_print_IAR_label() (these get generated because the address being > printed is now the lma, not the vma), since such labels cause errors in the > IAR assembler. > > > I guess that this should really be made as a patch in some way, but I don't > know how that works, and I think the changes I made should be added in a > neater way (for example, it is not good to have objdump_print_IAR_label() > declared with a parameter "vma" and then pass the lma to it). I also > haven't thought through any possible consequences of these changes, and for > some reason part of the data section turns up in disassembly (ugly, but it > works), and part as a raw DW data dump (much neater). Also, it's 21:45, and > the project has to be working for tomorrow, so I'm going to have to skip the > nicities for now. > > mvh. > > David > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > 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 ********************************************************************/
