This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

modify gcc to handle byteorder issue automatically


Hi people!

I've got a lot of stream processing (unpacking, encryption/decryption etc) C/C++ code - total size is about 350Mb.
Unfortunately all this code heavily depends on host byte-order, because it was written for little-endian machines, and no one cared about byte order issues.
Now I need to make this code run on ARM (Big-Endian) CPU. From my expirience, I know that 
most problems are caused by dereferencing word/dword pointers, and by accessing unaligned words/dwords natively.
To simplify this task, I want to patch GCC - either to show me "problematic" pieces of code, or even generate special code to automatically convert byte order issues.
I know this will not be a perfect solution, but I don't need a perfect solution anyway.
I've studied GCC sources, and now I know that both dereferencing operators, like:

*((unsigned int) a) = 0x01;
unsigned int flag = *((unsigned int) a);

generate the same INDIRECT_REF tree entry. So all that I need is:
1. Check whether standard short/int type (or it's typedef'ed alias) is dereferencing. If not, continue;
2. If this is rvalue, add several LSHIFT/OR ops after INDIRECT_REF, so returned value will be converted from LE to BE byte order automatically.
3. If this is lvalue, add several LSHIFT/OR ops before INDIRECT_REF, so stored value will be converted from LE to BE byte order automatically.

So I've got a few questions:

1. Where is the best place to add this functionality? During tree generation? 
During RTL emition? After RTL is generated?
2. Seems like access to structure members does not generate INDIRECT_REF. Why?


Best regards, Tim.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]