On May 11, 2006, at 10:44 PM, Chris Espinosa wrote: 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.
The problem is that my two targets link to two different versions of my library (debug to debug; release to release). I'm not aware of a way to add a library to one target but not another, other than by using the linker flags. Do you know a way? We spent quite a while last WWDC trying to find a better approach with no success... but maybe XCode has new options now? Short of adding new features to do this sort of linking, it would be great if XCode could recognize this situation from the linker flags and handle the dependency properly, unless there's some specific reason why it shouldn't...
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.
This is for x86, where misaligned vector loads are legal, but use a different load instruction. My code is trying to read 16 contiguous bytes from an array, from an arbitrary (possibly misaligned) starting index. Something like this:
vuint8 load(uint8* p) { return *(vuint8*)p; }
The compiler assumes that p is aligned and generates an aligned load instruction, which causes an alignment exception and crash. I would think that the compiler, not knowing whether the pointer is aligned, should not be making this assumption... Most stack-based data is known at compile-time to be aligned, but not arbitrary pointers. I haven't found this behavior documented anywhere one way or the other.
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.
I'm not necessarily looking for an interleaved view; just for a legible display of the assembly within XCode, short of compiling and running the entire program. This is particularly important when there are a thousand ways to write a bit of code, but only one that will make the compiler do the right thing... (This seems to happen a lot with gcc.) Having a tighter loop to see the assembly, go back and edit the code, see the assembly, etc. would be very useful.
Thanks again, Ben
|