DJ Delorie wrote: > Yes, that's pretty much what they asked for. However, it is still > somewhat ambiguous - for example, if you have an 8-bit "int" field, > which 4 bytes are read to get that field?
I haven't gone back just now to try to find the right words in the ABI, so I don't know for sure that they're there, but the intent is the types' natural alignment. All "int" bit-fields in that ABI are located within a 32-bit aligned range of memory; the intent is that you read/write that entire 4-byte range. In other words, take the byte address of the start of the bit-field, mask off the two low-order bits, that's the 4-byte address to read. On an ARM, you can never cross a protection boundary in that way; you're never going to get a SEGV from the bytes you read in that way if you wouldn't have gotten one from the byte containing the start of the bit-field. Protection is done at the page (or cache-line, I forget) boundary; in either case, the granularity of protection is greater than the granularity of any basic type. And, if it's not, that's your problem; the ABI semantics of a volatile bit-field of type T are that you get sizeof(T) bytes, and if it blows up (which I don't think it can), it's not the compiler's fault. If you have an ABI where an int bit-field can cross a sizeof(int)-byte boundary, that's a harder case. That can happen on ARM with GCC's packed-structure extension, but that's outside the ARM ABI, and therefore the behavior is not specified. > We need to figure out how much information we should pass to the > target to let it make these decisions, if it needs to. A common > function to do by-type access could be called from your target and > mine. I'd like to know how many of the assumptions above are valid on your target. I would imagine that many of them are. In which case, the existing hook is good enough; we just need to implement middle-end behavior depending on the hook. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
