As someone who totally has no idea what this means (well, I do sort of, which is probably even more dangerous than none at all), let me just share that this looks important and that I do hope that, if it is, it will be dealt with, if it isn't, will be moved out of the way as a problem.
YET, in any case, I want to thank you all of those who do understand this and do worry about it being right, and do fix it - otherwise the rest of us would have to depend on the goodwill of proprietary software that we would have no information on how it has issues, and/or/maybe is getting better - or not. THANK YOU, Peter, and all the rest of you Yama 2012/2/14, Peter Bigot <big...@acm.org>: > Take-away: > > In the existing msp430-as, there is NO BEHAVIORAL DIFFERENCE between these > two statements: > > mov &extern, r15 > mov extern, r15 > > And that is flat out wrong. If you have assembly code that depends on > these being equivalent, it will break with the next release of mspgcc. An > ampersand will be required to produce absolute offsets. > > The details: > > While reviewing the binutils port, I've found a frighteningly large number > of bugs in assembly and disassembly, especially in the 430X instructions > and in addressing modes not normally produced by gcc. Ten of them were bad > enough to be reported on the > tracker<https://sourceforge.net/tracker/?group_id=42303&atid=432701>. > The suite of bugs affecting symbolic addressing mode are what I'm afraid > of: correcting them will break currently working, but incorrect, assembly > code. > > Here's the situation: MSP430 supports two addressing modes that involve > constant offsets: "symbolic" is PC-relative, and "absolute" is, well, > absolute. Symbolic is implemented by adding an offset to the value of r0 > (=pc); absolute by adding an offset to r2 (=cg1 configured to read as zero). > > In assembly code the instruction: > > mov &0x1000, r15 > > loads the word at address 0x1000 into r15. This is absolute mode. > > The similar instruction: > > mov 0x1000, r15 > > is in symbolic mode. If the opcode for mov is at address 0x2000, then the > word at address 0x3002 (i.e., 0x2002+0x1000) will be loaded into r15. (The > extra 2 is because pc was incremented after reading the opcode.) > > So: LTS-20110716, which has essentially the same binutils that's been in > mspgcc for years, converts this: > > .global extern > mov &0x1000, r15 > mov 0x1000, r15 > mov &extern, r15 > mov extern, r15 > > into this: > > 00000000 <test>: > 0: 1f 42 00 10 mov &0x1000,r15 > 4: 1f 40 fa 0f mov 0x0ffa, r15 ;PC rel. 0x01002 > 8: 1f 42 00 00 mov &0x0000,r15 > a: R_MSP430_16 extern > c: 1f 40 00 00 mov 0x0000, r15 ;PC rel. 0x00010 > e: R_MSP430_16_PCREL_BYTE extern > > Absolute addressing mode is fine at this point, but symbolic mode has a > couple flaws. First, the specified value 0x1000 was improperly adjusted > based on an assumption that the value would be stored at offset 6 (which it > is at this point). The result is that the address that would actually be > read is 0x1000, rather than 0x1000+r0 which is what the instruction should > have meant. This subverts the intent of symbolic addressing mode by making > it effectively the same as absolute addressing mode. It's also wrong, > because at this point the code is still relocatable and final address > hasn't been determined: it probably won't be 6. (Note the "PC rel" comment > suggests the address that would be read is 0x1002; it's not, because of bug > 3487360<https://sourceforge.net/tracker/?func=detail&aid=3487360&group_id=42303&atid=432701>. > Does your head hurt yet? Mine does.) > > Now, if you take that relocatable code and pass it through the linker with > extern defined as 0x1000 and the text section starting at 0x6000, you get: > > 6000: 1f 42 00 10 mov &0x1000,r15 > 6004: 1f 40 fa 0f mov 0x0ffa, r15 ;PC rel. 0x07002 > 6008: 1f 42 00 10 mov &0x1000,r15 > 600c: 1f 40 f2 af mov 0xaff2, r15 ;PC rel. 0x01002 > > Again, absolute mode is correct, and symbolic mode has made another attempt > to convert the offset so that an absolute address is read. Ignore the > decoding error in the comment, because in practice the last two > instructions would both read a word from offset 0x1000. > > These errors will not be fixed in LTS-20110716. > > However, unless somebody can convince me this analysis is wrong (which is > part of why I'm posting this), in the next development release of mspgcc > the original code will produce: > > 6000: 1f 42 00 10 mov &0x1000,r15 > 6004: 1f 40 00 10 mov 0x1000, r15 ;PC rel. 0x07006 > 6008: 1f 42 00 10 mov &0x1000,r15 > 600c: 1f 40 00 10 mov 0x1000, r15 ;PC rel. 0x0700e > > For the most part, the gcc port does not emit code that uses symbolic mode, > so these bugs haven't been affecting it. There are a couple cases where it > does, and those will have to be fixed too. But it's assembly-language > coders who will have to fix their code if they've been using symbolic mode > where they should have been using absolute mode. > > Peter > ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
