|
disassemble, assembly question
Hello All,
0x0000002a9b0017c5 <func_instance+661>: mov %r12,%rdi 0x0000002a9b0017c8 <func_instance+664>: lea 0x48(%rsp),%rsi 0x0000002a9b0017cd <func_instance+669>: mov 0x8(%r12),%rax 0x0000002a9b0017d2 <func_instance+674>: callq *0x7b8(%rax) Can some body help me to understand what the above instructions does? the above output is from gdb, dissassemble func_instance. thank you in advance. Thanks, Deenadayalan |
At the start of this code r12 points to some object.
mov %r12,%rdi rdi is used to pass the first argument to a function. But in object oriented programming (which this seems to be) the address of the object is a hidden first argument. So the first instruction puts the address of some object into rdi. lea 0x48(%rsp),%rsi rsi is used for the second argument (first explicit argument for object oriented). The lea instruction sets rsi to the address of some object that is a local variable of the current function (an offset from rsp). Since just the address is loaded, the one explicit argument of the function must be passed by either pointer or reference (in asm code you can't tell the difference between pointer and reference). mov 0x8(%r12),%rax This must be getting the vtable address. I don't know why the vtable address is at offset 8 of the object, instead of offset 0. Maybe this isn't C++ (which I'm used to looking at). Anyway, the instruction loads some kind of pointer from offset 8 of the object that is now pointed to by both r12 and rdi. callq *0x7b8(%rax) Then the function is called, I think indirectly through the vtable. But if that really is a vtable, it's a very big one (lots of virtual functions). rax points to a vtable or something like a vtable. offset 0x7b8 in that table contains a pointer to a function. That is the function called. All the above is just an estimate. There is no way to look at disassembly and be certain what it means (in high level programming terms). |
Like johnsfine said, the assembly snippet is reading some local variable/data object from the stack ("lea 0x48(%rsp),%rsi"), dereferencing an address (again, "lea 0x48(%rsp),%rsi"), then calling the subroutine or method it finds at that address ("callq *0x7b8(%rax)").
Definitely sounds like an object method call (possibly C++, possibly not) to me, too. Also, the "callq" implies that maybe this is a 64-bit executable. 'Hope that helps.. PSM |
Johnsfine and paulsum
Thank you very much for your valuable information. I would like to understand and learn this assembly language, can you please point me some online tutorials and whats the best way to learn this assembly language (gnu disassembler assembly). if you have any assembly tutorials in your computer, please send me to my email id dayalan_cse@gmail.com Thank you in advance for your help. Thanks, Deenadayalan |
There are three major topics you need to understand to read that kind of disassembly:
1) AMD64 assembly language. For this example, it would tell you things like what each instruction opcode does, how the addressing modes work, etc. 2) GNU assembly language. GNU uses certain generic assembly language rules across architectures, so the GNU assembly language for AMD64 is different from AMD64 assembly language in several ways, such as: Operand order: On some architectures including AMD64 the official assemby language use a TO,FROM operand order. GNU assemby on all platforms uses FROM,TO % as a prefix for each register name Size suffixes on some instructions, such as the q on the call instruction. 3) The AMD64 ABI, which tells things such as the use of rdi and rsi as the first two (non floating point) arguments in a function call. I got all the AMD64 documentation I have from AMD's developer web site (which has been restructured since last I looked, so I can't link to exactly what I have). This is a good (at least today) link for documentation http://developer.amd.com/documentati...s/default.aspx In the middle of that page, it says AMD64 Architecture Programmer's Manual Volume 3: General-Purpose and System Instructions That is the main resource for my item (1) above. I got the ABI from AMD's site as well. I can't find it there now, but it is also at x86-64.org http://www.x86-64.org/documentation/ If you already know 32-bit GNU assembly, there is also a link there to a page that explains the basic changes from 32-bit to 64-bit assembly. As for item (2) above, tutorials (mainly 32-bit) are linked to from so many threads at LQ, I assume you can do your own search. |
Quote:
the additions of memory pokes leads me to believe it's hack code, specifically for destabilizing memory addressing. Could be what some of us call "Ghost Code", offered as a pkg. for chasers of it... |
I don't get the joke.
Quote:
I do have a habit of failing to see the joke in a technical post. I really don't see it this time. I hope no one trying to learn things from this thread takes your post seriously. |
Hi Johnsfine,
0x0000002a9b0017c5 <func_instance+661>: mov %r12,%rdi 0x0000002a9b0017c8 <func_instance+664>: lea 0x48(%rsp),%rsi 0x0000002a9b0017cd <func_instance+669>: mov 0x8(%r12),%rax 0x0000002a9b0017d2 <func_instance+674>: callq *0x7b8(%rax) I really appreciate for your help on the explanation for the above assmebly code. I have another question, I understand that writing data in to un-allocated memory in the application would cause the core dump but what about the above registers (%rax, %rdi ...). my understanding is that "these are machine registers" not required to allocate memory and writing values in to these set of registers would never make a crash. Is it correct? Thanks, Deenadayalan |
Hi Johnsfine,
============================================================= 0x0000002a9b0017c5 <func_instance+661>: mov %r12,%rdi 0x0000002a9b0017c8 <func_instance+664>: lea 0x48(%rsp),%rsi 0x0000002a9b0017cd <func_instance+669>: mov 0x8(%r12),%rax 0x0000002a9b0017d2 <func_instance+674>: callq *0x7b8(%rax) ============================================================= To be precise, i am doing the below. emp *e1; e1 = (void*) ( Array[0] | ( (long) Array[1] << 32 ) ) assume Array[0] 0x735ec100 assume Array[1] 0x0 Now ( (long) Array[1] <<32) => should return 0x 00 00 00 00 00 00 00 00 Then i am doing type casting using (void*) now i assume the e1 assignment becomes $r12 (its object). What value you would expect in $r12? Here is my observation is ==> $r12 is 0xff ff ff ff 73 5e c1 00 The crash happens at "mov 0x8($r12), %rax" because i see "0x ff ff ff ff" appended as upper 32-bits. but it should not instead it should be "0x 00 00 00 00 73 5e c1 00". some thing is wrong, is it gcc/machine/my code? Please help me to understand. Thanks, Deenadayalan |
Quote:
So you didn't show the disassembly for the part for which you showed source and you didn't show source for the part for which you showed disassembly. I don't know whether to trust your guess that you are even looking at the section of disassembly you think. Quote:
Quote:
|
I don't know whether to trust your guess that you are even looking at the section of disassembly you think.
Yes, i am looking at correct section of disassembly. Do you have any idea, why the Array[8] and ((long) Array[9]<<32) conversion in e1 (that is $r12) the upper limit has "0x ff ff ff ff" but Array[9] has 0. Please help me to understand. |
Quote:
But if I must start guessing which thing(s) you have said are incorrect, I could guess almost anything. If you provided more info, I wouldn't need to guess. The disassembly of the code that computes e1 might help a lot to explain how e1 got the unexpected value. |
Hi Johnsfine,
< assume the true value was at least 0x80000000 > You are right, its wrong address. The correct address is 0x89 06 00 70 As you said its signed integer variable. How does its getting extended for singed integer variable ( i understood, interger size is 4 byte on amd64 and the value 2^32/2 till is signed and if it cross than this value then it would represent as negative value) and how does this getting 0x ff ff ff ff extended for it in the above conversion (Array[8] | ( (long) Array[9] <<32) )? Please help me to understand. Thanks, Deenadayalan |
When you convert a signed 32 bit value to 64 bits, the low 31 bits of the new value will be the low 31 bits of the old value and each of the high 33 bits of the new value will be equal to the high 1 bit of the old value.
Since you don't want that to happen, you need to do your cast a different way. Here are two good choices instead of: Code:
e1 = (void*) ( Array[8] | ( (long) Array[9] << 32 ) );Code:
e1 = *(void**)(Array)[8/2];2) Cast to unsigned before the implicit cast to long Code:
e1 = (void*) ( (unsigned int)Array[8] | ( (long) Array[9] << 32 ) );Array[8] is cast from int to unsigned int. Then because it is to be combined with a long across the '|' the compiler implicitly casts it to long. Because it is unsigned, that implicit cast to long happens without the time cost or the error introduced by sign extension. |
Hi Johnsfine,
I really appreciate for your valuable information. Thank you very much for your information. < When you convert a signed 32 bit value to 64 bits, the low 31 bits of the new value will be the low 31 bits of the old value and each of the high 33 bits of the new value will be equal to the high 1 bit of the old value. > Do you mean, the new value of 32-63 bits will have by default high as binary value 1 so it becomes 0x ff ff ff ff <0-31 old value> ? Thanks, Deenadayalan |
Quote:
If the old value was 0x0000000 through 0x7FFFFFFF the new value will be 0x00000000<0-31 old value> but if the old value was 0x80000000 through 0xFFFFFFFF the new value will be 0xFFFFFFFF<0-31 old value> When I used the word "high" in my previous attempt to explain, I meant high bit positions within the 32 or 64 bit integer, not the high bit value (1). |
Help with a simlar question
I was going through this thread and I thought my problem/question is similar to this one..
0x00007ffff3e98f09 <func_instance+345>: jo 0x7ffff3e98f0f <func_instance+351> 0x00007ffff3e98f0b <func_instance+347>: mov 0x10(%rsp),%rdi 0x00007ffff3e98f10 <func_instance+352>: callq 0x7ffff3e1a1f8 <func_instance@plt> 0x00007ffff3e98f15 <func_instance+357>: mov 0x8(%rsp),%rdx 0x00007ffff3e98f1a <func_instance+362>: mov %rax,%rsi 0x00007ffff3e98f1d <func_instance+365>: movzbl 0x4f(%rax),%eax 0x00007ffff3e98f21 <func_instance+369>: cmp 0x4f(%rdx),%al 0x00007ffff3e98f24 <func_instance+372>: je 0x7ffff3e98fa0 <func_instance+496> 0x00007ffff3e98f26 <func_instancej+374>: mov (%r12),%eax End of assembler dump. I am hitting a SIGSEGV(NULL pointer dereference) on the below instruction: <TAG> 0x00007ffff3e98f1d <func_instance+365>: movzbl 0x4f(%rax),%eax </TAG> Can anyone elaborate a little more on these instructions. I have a very basic understanding though. Platform is an ia64 |
What they're talking about is sign extending. (Maybe that's not the correct term but I think you get what I mean.)
If the quantity that you are dealing with is assumed to be a 32-bit signed quantity, then the most-significant bit (MSB) is a sign-bit and the number is in so-called two's complement notation. The quantity "-1" is $FFFFFFFF, in the customary hexadecimal. If you load this 32-bit signed quantity into a 64-bit accumulator, the leftmost bit (the sign-bit) is extended into all of the unoccupied slots, since the 64-bit version of "-1" is of course $FFFFFFFFFFFFFFFF, thus correctly preserving its two's-complement representation. Now, what if you, the almighty programmer, assert that the value is, in fact, unsigned? (Obviously, it's impossible to tell one from the other by looking at the bits...) In this case, $FFFFFFFF is the decimal quantity 4,294,967,296 and the proper way to load it into a 64-bit register produces $00000000FFFFFFFF. Certainly, one of the "gotchas" of 64-bithood is that int is signed, and that it is also carelessly used as being "synonymous with a pointer," which in this case is no longer true. If you assumed a 32-bit world, then you could simply handle these quantities with impunity ... just ignore the MSB when you wanted to. But, now, sign-extending is occurring rather constantly if the word-size of the data you're dealing with is still 32-bits but now your CPU speaks 64. Suddenly, all of the leftmost-bits of your derived address (as many as your hardware actually cares about ...) have transmogrified themselves into 1's, and you are not looking anywhere near the right place in memory anymore. C'est la guerre... |
Quote:
Quote:
Based on the subsequent code, I expect that function was declared as returning a pointer to some struct type but when called, it returned a zero (NULL pointer). In x86_64 pointers are returned from functions in %rax Code:
0x00007ffff3e98f1d <func_instance+365>: movzbl 0x4f(%rax),%eaxBut you are reporting that it instead causes a NULL pointer dereference, so I assume %rax had zero in it before executing that instruction. Quote:
Quote:
Code:
jo 0x7ffff3e98f0f <func_instance+351>Code:
mov 0x10(%rsp),%rdiCode:
callq 0x7ffff3e1a1f8 <func_instance@plt>Code:
mov 0x8(%rsp),%rdxCode:
mov %rax,%rsiCode:
movzbl 0x4f(%rax),%eaxif ( x->f != y->f ) where x is the struc pointer loaded earlier into %rdx from a local variable and y is the struct pointer returned by the function call and f is the char at offset 79 in the struct. |
You are correct, thank you ... I replied on the original.
There are several reasons why such code can "fall down," and one of the very common reasons are differences in the so-called subroutine calling conventions that are being used. How does the caller supply arguments to the callee? This usually crops up when the code being called was compiled at a different time and perhaps by a different compiler, e.g. the target code is in a library of some kind. But, if the calls work anywhere in the application, this cannot be the problem. Most of the time, if you find yourself diving down into assembly-language instructions, you are chasing a pointless red herring. The assembly code, whatever it may be, may be presumed to be "correct." The root cause of the problem must be chased down and understood, and it will inevitably be somewhere in your code but it probably is not terribly close to the point where the application fell off its log footbridge and landed face-down in the mud of the debugger. I can count on the fingers of one hand the number of times when I successfully used a low-level debugger to usefully solve anything in application programming. |
Quote:
But... Quote:
So I can count on the fingers of one hand the number of times this year (2012) that I successfully used asm level debugging to solve a problem in application programming that couldn't be solved otherwise. But it is still fairly early in the year. Longer term, it seems to happen less than once a week, but not a lot less. |
Quote:
yes rax had zero in it before executing the instruction; Code:
movzbl 0x4f(%rax),%eax[p/x $rax & p/x $rsi] both of them returned 0. basically the function called in callq has returned a NULL. I shall paste the function code tomorrow and the formal parameter being passed to the function is an unsigned int(once i post the func, may be it will be clearer). Again, thank you for your brilliant thoughts. |
Quote:
2) If it is an unsigned int, why is it passed by copying a 64 bit local variable into a 64 bit register? If the actual parameter were 64 bit and the formal parameter were unsigned int and the function were properly declared for the calling module, I think the compiler would have chosen a more efficient instruction to pass the parameter (but I'm not certain of that and the less efficient instruction should not be functionally incorrect). |
The parameter passed to the function in callq is a const unsigned int. The function being called is the overloaded subscript operator
if (*(myRow[myCol[*loc].a]) == item) "a" is a member of a structure. Looking at asm code, myCol[*loc].a is null(UINT_MAX). By dereferencing it with myRow it hit the SIGSEGV! myCol[*loc].a should have had a valid value, it should not have returned UINT_MAX typedef struct { unsigned char a; }user; user *myCol; |
I can't connect the small snips of C++ code in your post #24 to the small chunk of asm code in your post #17.
If you are correct about passing unsigned int, I guess the %rdi could be incorrect disassembly in post #17. If you started the disassembly a few instructions earlier, so misalignment problems are resolved before reaching the previous instruction, we could be sure. You seem to be saying the function with the run time name func_instance@plt is an overloaded subscript operator returning a reference. Is that what you mean? If I understand you correctly, it is computing a reference to myCol[*loc] and that reference is an invalid pointer. But I don't follow what you are saying about UINT_MAX and especially not what you are saying about myCol[*loc].a. That is a character. You seem to be saying its value is invalid, but if that is related to the asm code you posted, it is the address myCol[*loc] that is invalid, not the value myCol[*loc].a. |
Quote:
typedef struct { unsigned int a; }user; the overloaded [] operator, it basically returns pointer to object stored at the index passed as a parameter. So what i was trying to say was; myCol[*loc].a was NULL when dereferenced caused the SEGV. |
That makes it even harder to see a connection with the disassembly you posted before.
I think the disassembly you posted before is a different if statement than the one you are looking at now. I assume the disassembly correctly represents the point of the seg fault, so I think you are looking in the wrong place in the source code for that seg fault. How big is func_instance ? If you post the whole source code to func_instance, I might be able to estimate the correct point of the seq fault. |
| All times are GMT -5. The time now is 02:21 PM. |