On May 11, 2006, at 10:28 PM, Ben Weiss wrote: 1. My app links to separate static libraries for debug and release versions, using linker flags -lMyLibrary and -lMyLibrary_d for the respective targets. This works fine, but when I recompile the library, the application project doesn't recognize that the libraries have changed; I have to clean and rebuild the application every time to make sure it incorporates the changed library. Is there a way to get this to happen automatically? (In other words, for the application project to recognize that the library is changed, and force a re-link on build?)
If you just add the libraries to the target they'll get linked for you, and dependency checking will work. If you enter file names as values in build flags, dependency checking doesn't know about them. 2. The CodeWarrior editor allows you to command-drag 2D blocks of text, then copy and paste over similar blocks. XCode's editor can also select 2D blocks with option-drag, but pasting over a similar block doesn't work correctly. (It introduces spurious newlines.) Is this a bug, and is there a way to make this work in XCode the same way it works in Codewarrior?
Unfortunately the behavior you describe (the 2D pasting) is a known limitation of Cocoa text rectangular selection and can be observed in all NSText views. It's on their list to fix across the board. 3. When a pointer (to say, a char) is cast to a vUInt16* pointer, gcc implicitly assumes that it is 16-byte aligned, and loads data with movdqa. Is it legal for gcc to assume this? Do misaligned loads always have to be coded explicitly?
That depends processor model to processor model. Use the #pragma align directives to control alignment explicitly, but the compiler will never (knock wood) generate illegal instruction alignment for a particular processor. 4. (more of a Shark question, really...) When I show both Code and Assembly in a Shark profile for my app, over half the computation time is shown associated with a single line of code:
54.2% 2105 *buf = _mm_packus_epi16(ppl, ppr); ! LCP
This is clearly a bug (neither the pack nor the store should generate the LCP warning, for one thing, and this line of code should take a negligible amount of time); I'll try to isolate it in a test project and submit a bug report, but perhaps a Shark person may recognize what's going on?
Perhaps. That wouldn't be me, though. 5. The "Show Assembly Code" option in XCode is nearly useless, since the code is so cluttered with labels and the like. (In the function popup menu, I have to scroll through hundreds of labels to find my function.) Are there any options to view the assembly in a more simplified format, along the lines of CodeWarrior's disassembler?
The "Show Assembly Code" is not a disassembly of the generated binary but rather a display of the intermediate asm created by gcc. If you want to see a clearer depiction of the code, break in the debugger and choose Toggle Debug Display. You'll see the machine code and the source side-by-side. We don't have any interleaved view like in CodeWarrior.
Chris |