Hi, I use gcc to compile programs for the msp430, then objdump to generate iar assembly format files, that are then assembled and linked with iar's tools so that I can debug using C-Spy. Mostly this works fine, but I've noticed one definite problem that may be an indication of more problems.
When trying this with a particular build of my program, iar's linker complained about overlapping segments. Looking at the s43 file generated by objdump, I traced the problem to the instruction "xor.b 8(r1), r6" which turned up in the "Disassembly of section .data". The section really contains initialisation data, so it would make more sense to have this as DB data dumps rather than disassembly (see under) - but then I wouldn't have spotted this potential source for problems. One of the words that should be here is hex 0xE164, which objdump disassembles to "xor.b(r1), r6". However, when assembling this again, IAR uses the long format, generating "0xe156 0x0008". Being the wrong number of words, segments overlap and the iar linker dies. In this particular case, I can easily get round the situation (see below). But what if this particular instruction turned up in the main code (or similar ones - I read about the "push #4" and "push #8" bugs)? It looks like IAR's assembler is more careful, probably unnecessarily so, about producing long format instructions. If such instructions turned up in the real code, then the objdump assembly file would not re-assembler (with iar's assembler) to the same code - addresses would all be different. I suppose that the linker would give a segment overlap error again (since there are regular ORG statements in the disassembly), so we could tell that it was happening. But perhaps we should do something about it before it becomes a problem? The first thing would be to find out if there is a problem with the short-form of these instructions - maybe TI can help with that. If there could be problems with the short-forms, then the gcc assembler should be changed to use them. If not, then perhaps the easiest way to avoid the problem would be for the iar-mode objdump disassembler to produce DW codes for the problem instructions rather that the correct assembler codes - then there could be no conflicts. There are a couple of oddities in the generated "Disassembly of section .data". Assuming that there are initialised data sections in several modules, the first linked module gets its section without labels (other than __data_start), and with the data disassembled. The other sections get labels and are dumped nicely as DB hex dumps. I would guess it is probably an easy thing to fix, so that the first section is also a hex dump (my workaround for my problem was to add an initialised dummy variable to a module that gets linked before the problem one, which is then generated as a DB hex dump). I can probably help with fixing some of these issues (at least, once I've got this current project completed and handed to the customer :-), but I'd like other opinions before wading in beyond my depth. mvh. David
