Where Are Relocation Entries Stored in Flat Binaries? - c++

Please be attend to the following example. I have a C++ code that I want to compile under powerpc and generate the binary code.
#include <stdio.h>
int function(int x);
int myfunction(int x);
int main()
{
int x = function(2);
int y = myfunction(2);
return x + y;
}
int function(int x)
{
return x * myfunction(x);
}
int myfunction(int x)
{
return x;
}
I have two function calls: call function(2) and call myfunction(2). I compile this C++ code under powerpc‍‍‍. So, now I use the objdump to get the assembly behind the object file and that is as follows:
00000000 <main>:
0: 94 21 ff e0 stwu r1,-32(r1)
4: 7c 08 02 a6 mflr r0
8: 93 e1 00 1c stw r31,28(r1)
c: 90 01 00 24 stw r0,36(r1)
10: 7c 3f 0b 78 mr r31,r1
14: 38 60 00 02 li r3,2
18: 48 00 00 01 bl 18 <main+0x18>
1c: 7c 60 1b 78 mr r0,r3
20: 90 1f 00 08 stw r0,8(r31)
24: 38 60 00 02 li r3,2
28: 48 00 00 01 bl 28 <main+0x28>
2c: 7c 60 1b 78 mr r0,r3
30: 90 1f 00 0c stw r0,12(r31)
34: 80 1f 00 08 lwz r0,8(r31)
38: 81 3f 00 0c lwz r9,12(r31)
3c: 7c 00 4a 14 add r0,r0,r9
40: 7c 03 03 78 mr r3,r0
44: 48 00 00 0c b 50 <main+0x50>
48: 38 60 00 00 li r3,0
4c: 48 00 00 04 b 50 <main+0x50>
50: 81 61 00 00 lwz r11,0(r1)
54: 80 0b 00 04 lwz r0,4(r11)
58: 7c 08 03 a6 mtlr r0
5c: 83 eb ff fc lwz r31,-4(r11)
60: 7d 61 5b 78 mr r1,r11
64: 4e 80 00 20 blr
00000068 <function__Fi>:
68: 94 21 ff e0 stwu r1,-32(r1)
6c: 7c 08 02 a6 mflr r0
70: 93 e1 00 1c stw r31,28(r1)
74: 90 01 00 24 stw r0,36(r1)
78: 7c 3f 0b 78 mr r31,r1
7c: 90 7f 00 08 stw r3,8(r31)
80: 80 7f 00 08 lwz r3,8(r31)
84: 48 00 00 01 bl 84 <function__Fi+0x1c>
88: 7c 60 1b 78 mr r0,r3
8c: 81 3f 00 08 lwz r9,8(r31)
90: 7c 00 49 d6 mullw r0,r0,r9
94: 7c 03 03 78 mr r3,r0
98: 48 00 00 0c b a4 <function__Fi+0x3c>
9c: 48 00 00 08 b a4 <function__Fi+0x3c>
a0: 48 00 00 04 b a4 <function__Fi+0x3c>
a4: 81 61 00 00 lwz r11,0(r1)
a8: 80 0b 00 04 lwz r0,4(r11)
ac: 7c 08 03 a6 mtlr r0
b0: 83 eb ff fc lwz r31,-4(r11)
b4: 7d 61 5b 78 mr r1,r11
b8: 4e 80 00 20 blr
000000bc <myfunction__Fi>:
bc: 94 21 ff e0 stwu r1,-32(r1)
c0: 93 e1 00 1c stw r31,28(r1)
c4: 7c 3f 0b 78 mr r31,r1
c8: 90 7f 00 08 stw r3,8(r31)
cc: 80 1f 00 08 lwz r0,8(r31)
d0: 7c 03 03 78 mr r3,r0
d4: 48 00 00 04 b d8 <myfunction__Fi+0x1c>
d8: 81 61 00 00 lwz r11,0(r1)
dc: 83 eb ff fc lwz r31,-4(r11)
e0: 7d 61 5b 78 mr r1,r11
e4: 4e 80 00 20 blr
The interesting thing that wondered me is the line that do function calls:
18: 48 00 00 01 bl 18 <main+0x18>
...
28: 48 00 00 01 bl 28 <main+0x28>
As you see, both are the binary code "48 00 00 01", but one calls function and another calls myfunction. The problem is that how we can find the call target. As I found, the call targets are written on RELOCATION ENTRIES. Oh, everything is okay, I use the command below to generate the relocation entries and is as follows:
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000018 R_PPC_REL24 function__Fi
00000028 R_PPC_REL24 myfunction__Fi
00000084 R_PPC_REL24 myfunction__Fi
This entries are useful to find the call target. Now, I use the objcopy -O binary command to generate the raw binary file (flat binary).
objcopy -O binary object-file
My object-file is the elf32-powerpc. The output binary file shown in following block:
2564 0000 2564 0a00 93e1 001c 9001 0024
7c3f 0b78 3860 0002 4800 0001 7c60 1b78
901f 0008 3860 0002 4800 0001 7c60 1b78
901f 000c 801f 0008 2c00 0002 4182 003c
2c00 0002 4181 0010 2c00 0001 4182 0014
4800 0058 2c00 0003 4182 0038 4800 004c
3d20 0000 3869 0000 389f 0008 4cc6 3182
4800 0001 4800 004c 3d20 0000 3869 0004
3880 0014 4cc6 3182 4800 0001 4800 0034
3d20 0000 3869 0004 3880 001e 4cc6 3182
4800 0001 4800 001c 3d20 0000 3869 0004
3880 0028 4cc6 3182 4800 0001 4800 0004
3860 0000 4800 0004 8161 0000 800b 0004
7c08 03a6 83eb fffc 7d61 5b78 4e80 0020
9421 ffe0 7c08 02a6 93e1 001c 9001 0024
7c3f 0b78 907f 0008 807f 0008 4800 0001
7c60 1b78 813f 0008 7c00 49d6 7c03 0378
4800 000c 4800 0008 4800 0004 8161 0000
800b 0004 7c08 03a6 83eb fffc 7d61 5b78
4e80 0020 9421 ffe0 93e1 001c 7c3f 0b78
907f 0008 801f 0008 7c03 0378 4800 0004
8161 0000 83eb fffc 7d61 5b78 4e80 0020
We can find the 4800 0001 on it. But there is no relocation entries. Could any one please tell me how can I find the relocation entries?
Thanks in Advance.

Your relocation entries are discarded when you do the objcopy. From the manual:
objcopy can be used to generate a raw binary file by using an output
target of binary (e.g., use -O binary). When objcopy generates a raw
binary file, it will essentially produce a memory dump of the contents
of the input object file. All symbols and relocation information will
be discarded. The memory dump will start at the load address of the
lowest section copied into the output file.
For your raw binary to be useful, you have a few options here:
You can perform the relocations during the build process, so that your raw binary is ready to run. However, this means that the binary file needs to be run at a fixed address in memory.
Alternatively, you can produce an object file that does not require relocation - all address references need to be relative. Lookup "position-independent code" for more details.
Finally, you could also use some other way of generating the raw binary (instead of, or in addition to, the objcopy stage), which includes the relocation table in the output file, and then have your code manually process these relocations at runtime.
The choice here will depend on what you're trying to do, and what constraints your runtime environment has.

Related

What are these seemingly-useless callq instructions in my x86 object files for?

I have some template-heavy C++ code that I want to ensure the compiler optimizes as much as possible due to the large amount of information it has at compile time. To evaluate its performance, I decided to take a look at the disassembly of the object file that it generates. Below is a snippet of what I got from objdump -dC:
0000000000000000 <bar<foo, 0u>::get(bool)>:
0: 41 57 push %r15
2: 49 89 f7 mov %rsi,%r15
5: 41 56 push %r14
7: 41 55 push %r13
9: 41 54 push %r12
b: 55 push %rbp
c: 53 push %rbx
d: 48 81 ec 68 02 00 00 sub $0x268,%rsp
14: 48 89 7c 24 10 mov %rdi,0x10(%rsp)
19: 48 89 f7 mov %rsi,%rdi
1c: 89 54 24 1c mov %edx,0x1c(%rsp)
20: e8 00 00 00 00 callq 25 <bar<foo, 0u>::get(bool)+0x25>
25: 84 c0 test %al,%al
27: 0f 85 eb 00 00 00 jne 118 <bar<foo, 0u>::get(bool)+0x118>
2d: 48 c7 44 24 08 00 00 movq $0x0,0x8(%rsp)
34: 00 00
36: 4c 89 ff mov %r15,%rdi
39: 4d 8d b7 30 01 00 00 lea 0x130(%r15),%r14
40: e8 00 00 00 00 callq 45 <bar<foo, 0u>::get(bool)+0x45>
45: 84 c0 test %al,%al
47: 88 44 24 1b mov %al,0x1b(%rsp)
4b: 0f 85 ef 00 00 00 jne 140 <bar<foo, 0u>::get(bool)+0x140>
51: 80 7c 24 1c 00 cmpb $0x0,0x1c(%rsp)
56: 0f 85 24 03 00 00 jne 380 <bar<foo, 0u>::get(bool)+0x380>
5c: 48 8b 44 24 10 mov 0x10(%rsp),%rax
61: c6 00 00 movb $0x0,(%rax)
64: 80 7c 24 1b 00 cmpb $0x0,0x1b(%rsp)
69: 75 25 jne 90 <bar<foo, 0u>::get(bool)+0x90>
6b: 48 8b 74 24 10 mov 0x10(%rsp),%rsi
70: 4c 89 ff mov %r15,%rdi
73: e8 00 00 00 00 callq 78 <bar<foo, 0u>::get(bool)+0x78>
78: 48 8b 44 24 10 mov 0x10(%rsp),%rax
7d: 48 81 c4 68 02 00 00 add $0x268,%rsp
84: 5b pop %rbx
85: 5d pop %rbp
86: 41 5c pop %r12
88: 41 5d pop %r13
8a: 41 5e pop %r14
8c: 41 5f pop %r15
8e: c3 retq
8f: 90 nop
90: 4c 89 f7 mov %r14,%rdi
93: e8 00 00 00 00 callq 98 <bar<foo, 0u>::get(bool)+0x98>
98: 83 f8 04 cmp $0x4,%eax
9b: 74 f3 je 90 <bar<foo, 0u>::get(bool)+0x90>
9d: 85 c0 test %eax,%eax
9f: 0f 85 e4 08 00 00 jne 989 <bar<foo, 0u>::get(bool)+0x989>
a5: 49 83 87 b0 01 00 00 addq $0x1,0x1b0(%r15)
ac: 01
ad: 49 8d 9f 58 01 00 00 lea 0x158(%r15),%rbx
b4: 48 89 df mov %rbx,%rdi
b7: e8 00 00 00 00 callq bc <bar<foo, 0u>::get(bool)+0xbc>
bc: 49 8d bf 80 01 00 00 lea 0x180(%r15),%rdi
c3: e8 00 00 00 00 callq c8 <bar<foo, 0u>::get(bool)+0xc8>
c8: 48 89 df mov %rbx,%rdi
cb: e8 00 00 00 00 callq d0 <bar<foo, 0u>::get(bool)+0xd0>
d0: 4c 89 f7 mov %r14,%rdi
d3: e8 00 00 00 00 callq d8 <bar<foo, 0u>::get(bool)+0xd8>
d8: 83 f8 04 cmp $0x4,%eax
The disassembly of this particular function continues on, but one thing I noticed is the relatively large number of call instructions like this one:
20: e8 00 00 00 00 callq 25 <bar<foo, 0u>::get(bool)+0x25>
These instructions, always with the opcode e8 00 00 00 00, occur frequently throughout the generated code, and from what I can tell, are nothing more than no-ops; they all seem to just fall through to the next instruction. This begs the question, then, is there a good reason why all these instructions are generated?
I'm concerned about the instruction cache footprint of the generated code, so wasting 5 bytes many times throughout a function seems counterproductive. It seems a bit heavyweight for a nop, unless the compiler is trying to preserve some kind of memory alignment or something. I wouldn't be surprised if this were the case.
I compiled my code using g++ 4.8.5 using -O3 -fomit-frame-pointer. For what it's worth, I saw similar code generation using clang 3.7.
The 00 00 00 00 (relative) target address in e8 00 00 00 00 is intended to be filled in by the linker. It doesn't mean that the call falls through. It just means you are disassembling an object file that has not been linked yet.
Also, a call to the next instruction, if that was the end result after the link phase, would not be a no-op, because it changes the stack (a certain hint that this is not what is going on in your case).

RSAES_OAEP_SHA_Decryptor MaxPlaintextLength returning zero

I have to write a small authentication server that, when a client connects, sends a RSA public exponent and modulus to it, and the client returns the username and password encrypted with them. The part where I get the exponent and modulus works fine, the client receives them, and sends the encoded block back; that's not a problem. The problem is in decoding it: the RSA Decryptor always returns 0 as MaxPlaintextLength, and no matter how many different ways I try to move the data around, I can't get it to work.
I'm providing hex dumps of the different parts after the code.
// These are static in the namespace to keep the key loaded.
static CryptoPP::AutoSeededRandomPool rsaRng;
static CryptoPP::InvertibleRSAFunction rsaParameters;
static CryptoPP::RSA::PrivateKey rsaPrivateKey(rsaParameters);
// This is done when the client connects.
{
rsaPrivateKey.GenerateRandomWithKeySize(rsaRng, 1024);
// This is where GetPublicExponent() and GetModulus() are
// encoded and sent to the client. They are sent correctly
// and I receive the encrypted data in a char buffer.
}
// This runs when I receive the encrypted data, which starts
// at &dataBuffer[7] and has a length of rsaPayloadLen.
{
int rsaPlainSize;
byte *rsaBuffer;
rsaBuffer = new byte[rsaPayloadLen];
memcpy(&rsaBuffer[0], &dataBuffer[7], rsaPayloadLen);
CryptoPP::SecByteBlock rsaCypher(rsaBuffer, rsaPayloadLen);
CryptoPP::RSAES_OAEP_SHA_Decryptor rsaDecryptor(rsaPrivateKey);
// At this point I inspected rsaCypher and it does contain the
// expected binary data, and rsaCypher.size() returns 256.
rsaPlainSize = rsaDecryptor.MaxPlaintextLength(rsaCypher.size());
// rsaPlainSize is 0. I have no idea why!
}
Hex dumps of everything at the time of calling MaxPlaintextLength:
rsaPrivateKey.GetPublicExponent():
000000: 11 .
rsaPrivateKey.GetPrivateExponent():
000000: 10 7a fd fd 9e a9 72 8c c3 5d 5b 80 e8 f4 6f bc .z....r..][...o.
000010: bc 6a 7a 51 4f 9f af d3 e4 76 a5 4a 9d fe 17 37 .jzQO....v.J...7
000020: 03 cf 82 24 33 e2 a0 d8 97 26 0a 6b ac 9d b1 de ...$3....&.k....
000030: 39 d5 3a 93 aa 65 66 be 17 43 3c 00 20 77 68 0a 9.:..ef..C<. wh.
000040: ac 2f 77 1e b8 c4 7f 64 52 54 7c 17 54 b6 e6 a4 ./w....dRT|.T...
000050: 95 49 60 7b 7b 16 6a 41 72 54 03 a2 2d 3a 80 8b .I`{{.jArT..-:..
000060: aa 74 fa 77 22 5d 0a d9 81 b2 b2 48 01 db 43 e8 .t.w"].....H..C.
000070: 16 1c c4 c3 a6 bf 45 7e 90 d3 6a 37 10 40 9f 71 ......E~..j7.#.q
rsaPrivateKey.GetModulus():
000000: d2 20 26 61 a6 f0 74 82 ba e6 4e ab 9a 2c 90 a6 . &a..t...N..,..
000010: 62 4d 97 8c b7 34 01 cd a0 e8 bb 77 5e 67 a7 fd bM...4.....w^g..
000020: 70 95 bb 4d 95 89 82 c9 87 25 04 dc d8 da 9b d1 p..M.....%......
000030: 61 5e aa da bc 8c dd f7 a8 99 3d 01 9d f2 6e 89 a^........=...n.
000040: e4 75 ec 91 31 e9 86 f4 da 43 4a ca a4 66 6b 04 .u..1....CJ..fk.
000050: c2 c9 a1 18 1d fa 81 b0 6e ef a5 13 04 44 88 89 ........n....D..
000060: 42 41 be 9c 7c 77 75 96 50 07 70 ad eb 60 e5 05 BA..|wu.P.p..`..
000070: aa a8 d8 27 03 28 cf bb c7 f5 cb 0d b3 b3 96 7f ...'.(..........
rsaPrivateKey.GetPrime1():
000000: d7 9e af ac e4 04 42 e4 58 9c 39 19 0e 56 7c ef ......B.X.9..V|.
000010: b3 bf b6 26 73 25 d8 ab d7 5e d1 e0 56 49 ae 66 ...&s%...^..VI.f
000020: c4 d8 81 bc d0 be c2 ef f4 6a 09 72 ef 72 35 7e .........j.r.r5~
000030: 15 f4 f9 3b f8 be f9 3a a1 0d 3e d0 eb c8 34 11 ...;...:..>...4.
rsaPrivateKey.GetPrime2():
000000: f9 7a 0e 1c 9a 1b eb d1 67 f1 e3 88 1d f3 f1 62 .z......g......b
000010: 9f a2 5c cb 49 76 de 42 25 e1 a4 de ed 50 f3 2d ..\.Iv.B%....P.-
000020: c0 15 c3 70 b5 96 68 51 25 f7 06 24 e4 43 0d b8 ...p..hQ%..$.C..
000030: 7a c5 12 2c 7c 63 20 73 70 61 01 fe b8 b3 71 8f z..,|c spa....q.
Plain text buffer that was encrypted:
000000: 73 74 72 69 6e 67 62 75 66 66 65 72 00 00 00 00 stringbuffer....
000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..............
rsaCypher:
000000: 0e 9e bd 34 10 16 98 a5 b8 e4 0c 9b 4f 23 71 6d ...4........O#qm
000010: af d6 e8 c1 4d 97 b9 32 cb 25 eb 01 fe 4f 5c 79 ....M..2.%...O\y
000020: 2d d8 32 c4 4f fa e9 2e 58 dd fd 37 7f 08 97 d8 -.2.O...X..7....
000030: 95 bb 6f 04 46 fa 83 77 05 01 43 75 ca be b4 4a ..o.F..w..Cu...J
000040: 60 f9 e7 4a 91 3d bc ac fb e9 41 f3 9d b7 df d3 `..J.=....A.....
000050: a7 03 80 3a 7f 35 98 46 ca 06 b1 f3 d1 7b 56 83 ...:.5.F.....{V.
000060: 1b 00 7d 97 59 39 be 46 d5 cf 6d 2c b3 a7 8e 30 ..}.Y9.F..m,...0
000070: 39 ca ca d5 59 a2 71 43 e7 7e 75 b3 3c d6 a3 a5 9...Y.qC.~u.<...
000080: aa 89 e3 e9 32 e1 a9 c1 a5 a8 f5 66 be 7f c9 ba ....2......f....
000090: 65 35 0f 61 a0 d4 fa c7 ac 8e 28 7c 39 26 3f 01 e5.a......(|9&?.
0000a0: 34 ad 82 69 5e c4 ab 92 48 47 42 04 02 48 79 c4 4..i^...HGB..Hy.
0000b0: 39 6e f2 2c 7c 19 71 34 36 38 1c eb c1 f2 33 f0 9n.,|.q468....3.
0000c0: 49 b9 7e bb c3 16 ed d7 f7 3e 10 a7 cc 2b 8c 31 I.~......>...+.1
0000d0: f1 17 c7 a5 49 ce dd a3 c6 e2 9c 3c 2f 37 e4 97 ....I......</7..
0000e0: ac b7 24 17 b3 f8 75 6f 2a 85 cb 23 7a e1 77 72 ..$...uo*..#z.wr
0000f0: 02 0b 90 28 9b 9b ff 5d 6f 9b 11 11 d3 8b dd 4b ...(...]o......K
rsaCypher.size(): 256
rsaDecryptor.MaxPlaintextLength(rsaCypher.size()): 0
I'm really completely at a loss and the only reason I've spent the whole weekend fighting this is because I'm going to need CryptoPP later for Blowfish and Adler32, otherwise I would have just used another RSA library.
RSAES_OAEP_SHA_Decryptor MaxPlaintextLength returning zero...
Your calculation of rsaPayloadLen is probably not correct. I would suggest you check the size of the ciphertext before you transmit it and after you recover it. I think its size is rsaPayloadLen in you code above.
From the comments in cryptlib.h:
//! maximum length of plaintext for a given ciphertext length
/*! \note This function returns 0 if ciphertextLength is not valid (too long or too short). */
virtual size_t MaxPlaintextLength(size_t ciphertextLength) const =0;
I cannot duplicate when I take plain text, encrypt it, and then pass ciphertext.size() into MaxPlaintextLength. I can duplicate if I pass ciphertext.size() - 1 into MaxPlaintextLength.
As a work around to get you a little further along, you might try using FixedMaxPlaintextLength(). It takes no arguments and only depends upon the public key length. You can use it to find the largest buffer based on the key. But you could fail on decryption.
You should probably show us your encryption code, too. You might not be sizing a buffer correctly.
The whole problem was the key size. The doc said I should use a 1024-bit key, but the other program was expecting a 1152-byte key; apparently that change was never documented. Everything works fine after changing a single line:
rsaPrivateKey.GenerateRandomWithKeySize(rsaRng, 1152);
Leaving this answer here in case someone else ever has this problem. Check the key sizes, and don't trust the documentation!

What is the ds:0023:003a3000=?? stuff on the end of a drwatson FAULT?

I have the following entry in a Dr Watson log. What is the significance of the "ds:0023:003a3000=??" part of the entry to the right of the FAULT line?
*----> State Dump for Thread Id 0xdfc <----*
eax=00000000 ebx=00390320 ecx=0854ff48 edx=09e44bfc esi=00012ce1 edi=0854ff61
eip=00465c51 esp=0854ff30 ebp=00000000 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
function: sysman
00465c37 49 dec ecx
00465c38 eb02 jmp sysman+0x65c3c (00465c3c)
00465c3a 33c9 xor ecx,ecx
00465c3c 8d542428 lea edx,[esp+0x28]
00465c40 52 push edx
00465c41 51 push ecx
00465c42 8d4c2418 lea ecx,[esp+0x18]
00465c46 e8d5c0fcff call sysman+0x31d20 (00431d20)
00465c4b 33c0 xor eax,eax
00465c4d 8d4c2418 lea ecx,[esp+0x18]
FAULT ->00465c51 8a441eff mov al,[esi+ebx-0x1] ds:0023:003a3000=??
00465c55 50 push eax
00465c56 6864074900 push 0x490764
00465c5b 51 push ecx
00465c5c e8cfd0fcff call sysman+0x32d30 (00432d30)
00465c61 8d542424 lea edx,[esp+0x24]
00465c65 68689f4800 push 0x489f68
00465c6a 8d44242c lea eax,[esp+0x2c]
00465c6e 52 push edx
00465c6f 50 push eax
00465c70 e83bc3fcff call sysman+0x31fb0 (00431fb0)
*----> Stack Back Trace <----*
ChildEBP RetAddr Args to Child
00000000 00000000 00000000 00000000 00000000 sysman+0x65c51
*----> Raw Stack Dump <----*
000000000854ff30 58 01 55 08 75 07 c8 09 - 00 00 00 00 18 6d c7 01 X.U.u........m..
000000000854ff40 fc 4b e4 09 04 bd 47 00 - 04 bd 47 00 fc 0c c9 01 .K....G...G.....
000000000854ff50 ac ca ae 09 64 5f c4 01 - 20 37 37 30 32 34 3a 20 ....d_.. 77024:
000000000854ff60 00 b3 42 00 a8 ff 54 08 - 90 a6 47 00 02 00 00 00 ..B...T...G.....
000000000854ff70 8b c5 42 00 b8 ff 54 08 - 2e 03 39 00 28 99 cb 01 ..B...T...9.(...
000000000854ff80 ff ff ff ff 00 00 00 00 - 00 00 00 00 20 1e cb 01 ............ ...
000000000854ff90 a6 f7 ba 77 06 00 00 00 - c9 f7 ba 77 e1 6b d9 09 ...w.......w.k..
000000000854ffa0 06 00 00 00 1f 00 00 00 - 68 00 55 08 c1 a0 47 00 ........h.U...G.
000000000854ffb0 00 00 00 00 58 c4 42 00 - c9 a5 ca 09 d1 fb 38 0a ....X.B.......8.
000000000854ffc0 27 00 00 00 e1 6b d9 09 - ef f2 41 00 c9 a5 ca 09 '....k....A.....
000000000854ffd0 01 59 cc 01 38 00 55 08 - ec 00 55 08 00 00 00 00 .Y..8.U...U.....
000000000854ffe0 e0 00 55 08 ff ff ff ff - 89 00 00 00 01 00 01 01 ..U.............
000000000854fff0 c8 ff 54 08 b8 ff 54 08 - 77 00 55 08 29 a5 ca 09 ..T...T.w.U.)...
0000000008550000 51 00 00 00 5f 00 00 00 - 00 9f 82 7c 61 36 ca 01 Q..._......|a6..
0000000008550010 25 00 00 00 3f 00 00 00 - 00 ce bb 77 91 b7 c7 01 %...?......w....
0000000008550020 19 00 00 00 1f 00 00 00 - 00 ff ff ff d9 28 cc 01 .............(..
0000000008550030 0b 00 00 00 1f 00 00 00 - 00 00 55 08 d1 fb 38 0a ..........U...8.
0000000008550040 27 00 00 00 3f 00 00 00 - 00 20 ba 77 00 00 00 00 '...?.... .w....
0000000008550050 00 00 00 00 00 00 00 00 - 20 b7 c7 01 00 00 00 00 ........ .......
0000000008550060 00 00 00 00 00 00 00 00 - b4 00 55 08 1b 90 47 00 ..........U...G.`
To summarize:
You get a register dump here:
eax=00000000 ebx=00390320 ecx=0854ff48 edx=09e44bfc esi=00012ce1 edi=0854ff61
eip=00465c51 esp=0854ff30 ebp=00000000 iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
The eip indicates the instruction that failed:
FAULT ->00465c51 8a441eff mov al,[esi+ebx-0x1] ds:0023:003a3000=??
The stuff at the end is the address that failed to read, which is the "usual" data segment of 23, and address 3A3000, whcih is composed of esi and ebx minus 1: 390320+12ce1-1. To me, that looks like an index gone bad - 3a3000 would be the first address of a new "page" in memory, so that's why it's failing at that point. 77025 bytes into an array is quite a long way, but it is of course possible that it's something else that is wrong.

Can pointer casts that only change const-ness invoke undefined behavior?

I stumbled over some code that appears to be correct.
It is supposed to provide a public, immutable pointer, while keeping the modifiable non-const pointer private.
Strangely enough, this code broke on SN C++ Compiler (for PlayStation 3), but worked fine on GCC. On SN C++, data would point to bogus values, while m_data would work as intended.
Code in question:
#include <cstdint>
class Foo
{
public:
Foo() : data((const std::uint8_t* const&)m_data)
{
m_data = nullptr; // Set later in some other member function.
}
const std::uint8_t* const &data;
private:
std::uint8_t* m_data;
};
Does this code invoke undefined behavior? As far as I know, casting to a reference like that will convert (const std::uint8_t* const&)m_data into *reinterpret_cast<const std::uint8_t* const*>(&m_data).
Test cases:
Foo* new_foo() { return new Foo; }
and looking at the generated disassembly. Note that it is PowerPC 64-bit with 32-bit longs and pointers.
SN C++: ps3ppusnc -o test-sn.o -O3 -c test.cpp
0000000000000000 <._Z7new_foov>:
0: f8 21 ff 81 stdu r1,-128(r1) # ffffff80
4: 7c 08 02 a6 mflr r0
8: f8 01 00 90 std r0,144(r1) # 90
c: fb e1 00 78 std r31,120(r1) # 78
10: 38 60 00 08 li r3,8
14: 3b e0 00 00 li r31,0
18: 48 00 00 01 bl 18 <._Z7new_foov+0x18>
1c: 60 00 00 00 nop
20: 2c 03 00 00 cmpwi r3,0
24: 41 82 00 38 beq 5c <._Z7new_foov+0x5c>
28: 30 81 00 70 addic r4,r1,112 # 70
2c: 93 e3 00 04 stw r31,4(r3) <-- Set m_data to r31 (0).
30: 60 7f 00 00 ori r31,r3,0
34: 90 83 00 00 stw r4,0(r3) <-- Set data to r4 (r1 + 112 (On stack)?!)
38: 63 e3 00 00 ori r3,r31,0
3c: e8 01 00 90 ld r0,144(r1) # 90
40: 7c 08 03 a6 mtlr r0
44: eb e1 00 78 ld r31,120(r1) # 78
48: 38 21 00 80 addi r1,r1,128 # 80
4c: 4e 80 00 20 blr
GCC 4.1.1: ppu-lv2-g++ -o test-gcc.o -O3 -c test.cpp
0000000000000000 <._Z7new_foov>:
0: 38 60 00 08 li r3,8
4: 7c 08 02 a6 mflr r0
8: f8 21 ff 91 stdu r1,-112(r1) # ffffff90
c: f8 01 00 80 std r0,128(r1) # 80
10: 48 00 00 01 bl 10 <._Z7new_foov+0x10>
14: 60 00 00 00 nop
18: 7c 69 1b 78 mr r9,r3
1c: 38 00 00 00 li r0,0
20: 39 63 00 04 addi r11,r3,4 <-- Compute address of m_data
24: 78 63 00 20 clrldi r3,r3,32 # 20
28: 90 09 00 04 stw r0,4(r9) <-- Set m_data to r0 (0).
2c: e8 01 00 80 ld r0,128(r1) # 80
30: 38 21 00 70 addi r1,r1,112 # 70
34: 91 69 00 00 stw r11,0(r9) <-- Set data reference to m_data.
38: 7c 08 03 a6 mtlr r0
3c: 4e 80 00 20 blr
You'll have to fight through the spec language in 4.4/4 (of C++11), but I believe that 3.10/10 permits this. It says that object may be aliased as "a type similar to the dynamic type of the object".
In this case, the dynamic type of the object is std::uint8_t*, and the similar type is const std::uint8_t* const. I think. Check 4.4/4 for yourself.
[Update: C++03 doesn't mention "similar" types in 3.10/15, so it may be that you're in trouble on C++03, which presumably is what SNC works with.]
There's a second thing that needs to be checked, which is whether it's OK to initialize the reference data by binding it to an object that hasn't been initialized yet (m_data). Intuitively that seems OK, since the reference to the uninitialized m_data is never converted to an rvalue. It's easily fixed, anyway.

How to read the model of monitor from the EDID?

In the registry there is one (or more) key depending how many monitors you have HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\DEL404C{Some Unique ID}\Device Parameters\EDID which is a REG_BINARY key. In my case this is :
00 ff ff ff ff ff ff 00 4c 2d 6f 03 39 31 59 4d
07 12 01 03 0e 29 1a 78 2a 80 c5 a6 57 49 9b 23
12 50 54 bf ef 80 95 00 95 0f 81 80 81 40 71 4f
01 01 01 01 01 01 9a 29 a0 d0 51 84 22 30 50 98
36 00 ac ff 10 00 00 1c 00 00 00 fd 00 38 4b 1e
51 0e 00 0a 20 20 20 20 20 20 00 00 00 fc 00 53
79 6e 63 4d 61 73 74 65 72 0a 20 20 00 00 00 ff
00 48 56 44 51 32 30 36 37 37 37 0a 20 20 00 ef
My question is how can I read only model of monitor ("SyncMaster" for example) and not all of the information using C or C++?
The format of EDID is described here: http://en.wikipedia.org/wiki/Extended_display_identification_data
What you're interested in here is the descriptor blocks of the EDID, which are found in the byte ranges 54-71, 72-89, 90-107, and 108-125. Here's those four blocks in your EDID:
#1: 9a29 a0d0 5184 2230 5098 3600 acff 1000 00
#2: 0000 00fd 0038 4b1e 510e 000a 2020 2020 20
#3: 0000 00fc 0053 796e 634d 6173 7465 720a 20
#4: 0000 00ff 0048 5644 5132 3036 3737 370a 00
You can identify the descriptor containing the monitor name because the first three bytes are all zero (so it isn't a detailed timing descriptor), and the fourth one byte FC (indicating the type). The fifth byte and beyond contain the name, which is here:
5379 6e63 4d61 7374 6572 0a20 SyncMaster..
So, in short: Check at offsets 54, 72, 90, and 108 for the sequence 00 00 00 FC; if you find a match, the monitor name is the next 12 bytes.