| Revision | 9ce226969c12b092ca0784a1b81c0973c59f53e7 (tree) |
|---|---|
| Zeit | 2016-10-27 17:08:17 |
| Autor | OCTAGRAM <bo_ <gen@octa...> |
| Commiter | OCTAGRAM <bo_ |
Yet another observation from SOM OR/M sample from VisualAge for C++
Known differences between SOM 2.1 and SOM 3.0.md (diff)| @@ -69,7 +69,7 @@ | ||
| 69 | 69 | |
| 70 | 70 | As soon as MSVC compiler is used for SOM 2.1 samples, the enum is 4 bytes and consistent with SOM DLL ABI, but VAC compiler is supposedly broken. /Sp1 should make the structure Environment packed, change size and offsets in Environment. That makes it harder to verify assumptions about ABI. The first option is IDA, it unveils how do original DLLs work with data. The second option is to construct custom tk_struct TypeCodes and check tcSize on them. |
| 71 | 71 | |
| 72 | -Also, IBM VisualAge C++ v3.5 has DirectToSOM sample, and it has independent flags: | |
| 72 | +Also, IBM VisualAge for C++ v3.5 has DirectToSOM sample, and it has independent flags: | |
| 73 | 73 | |
| 74 | 74 | DEBUGFLAGS=/Ti /O- /Os- |
| 75 | 75 | BROWSEFLAGS=/Fb |
| @@ -78,6 +78,28 @@ | ||
| 78 | 78 | |
| 79 | 79 | Note that "/Sp1 Packing of data items" is not present, and so is "/Su" for enum sizes. IDA shows that SOM_CreateLocalEnvironment() macro in xhmain.cpp expands into SOMCalloc for 16 bytes. So enum size might be 1 here, but aligned pointers after "exception_type" expand this structure into 16-byte one. Unfortunatelly, xhmain.cpp does not check __SOMEnv->_major. |
| 80 | 80 | |
| 81 | +Also, IBM VisualAge for C++ v3.5 has some kind of OR/M in SOM sample (IBMCPPW\SAMPLES\database\stocksom\CLIENT.CPP). It has yet another flags: | |
| 82 | +icc.exe /Tdp /Sn /Gh /Ti /Gm /Gd /I. /Fb /Fo"%|dpfF.obj" /C .\prclist.cpp | |
| 83 | + | |
| 84 | +Interesting to note, there is also no /Sp1 here. And also no "/Su". IDA shows that SOM.DLL clearly expects Environment._major to be 4 byte. Happily for us, this sample has exception handling code, and we can check our expectations: | |
| 85 | + | |
| 86 | + | |
| 87 | +``` | |
| 88 | +#!assembler | |
| 89 | + | |
| 90 | +txt0:00445E7C xor eax, eax | |
| 91 | +txt0:00445E7E mov al, [ecx] | |
| 92 | +txt0:00445E80 cmp eax, 2 | |
| 93 | +txt0:00445E83 jz short loc_445E97 | |
| 94 | +txt0:00445E85 cmp eax, 1 | |
| 95 | +txt0:00445E88 jz short loc_445EC0 | |
| 96 | +txt0:00445E8A test eax, eax | |
| 97 | +txt0:00445E8C jz loc_445FDA | |
| 98 | + | |
| 99 | +``` | |
| 100 | + | |
| 101 | +Gotcha! So in SOM 2.1 ABI enums (not only SOM enums, but system ones) must be 4 bytes because Microsoft C compiler was used to compile SOM 2.1, and it is supposed to be frozen afterwards. However, VisualAge C++ samples never use /Su compiler option to make their enums 4 bytes. They have seemingly got strange errors, but tried to cure them with alignment option as opposed to enum options. So far, there can be another strange errors. Wrt environment structure it is being initialized with zeroes, so there should be no problem. No matter if you read bytes or double words, you get the same result. But in some other circumstances (like emitters) one side might write byte and another one might read double word and get garbage. | |
| 102 | + | |
| 81 | 103 | And the final test is to use TypeCode_size on hand-made types: |
| 82 | 104 | |
| 83 | 105 |
| @@ -131,4 +153,4 @@ | ||
| 131 | 153 | |
| 132 | 154 | ``` |
| 133 | 155 | |
| 134 | -So, clearly, that's not just IBM developers mishandled compiler flags. That's indeed different ABI. But the issue with mishandled compiler flags is also present. | |
| 156 | +So, clearly, that's not just IBM developers mishandled compiler flags. That's indeed different ABI in SOM 2.1 and SOM 3.0. But the issue with mishandled compiler flags is also present. |
Fork