gdb in msys, doesn't show the name of the function call. Next to the address of the function call I have normaly the name of the function like . Why it's not the case with this exe and how can I fix it? gdb console
Why it's not the case with this exe
Because GDB doesn't know what function address 0x4023d0 corresponds to.
how can I fix it?
Depending on what code resides at address 0x4023d0, and why GDB doesn't have a name associated with it, this may or may not be fixable. But there is not enough info for me to even begin guessing what code might be there.
Related
I am just starting to learn Assembly (x86 NASM) and I am currently going over function calls. Wherever I looked on the internet I saw everyone calling functions like this:
call power
Where power is the label where the function starts. But what I am trying to see is how to print something in Assembly, and interestingly enough, calling a function like in the above case doesn't seem to work. We'll use the printf function from C. Say I already used extern printf and import printf msvcrt.dll in my program (so I can actually use printf), also say I already defined a symbol in my data segment msg db "Hello World", 0 and now I am trying to print this message. If I do this:
push dword msg
call printf
Nothing happens, it doesn't work. I have no idea why. However, if I do this:
push dword msg
call [printf]
The message is printed just as expected.
This doesn't make much sense to me after all the articles that I read used just the label, without brackets. It also made a lot of sense to me when using just the label as we're using the call instruction to perform a jump to that label, so we needed the address of the label. But here it doesn't make sense at all to me why we're using the brackets and what exactly happens. I mean, what is [printf] and what would [power] be, for the example I presented at the start of my question. However, despite my confusion, this is what works and the method I initially used doesn't work.
Can you please tell me exactly what is going on? (PS: I am using Olly Debugger if that makes any difference)
It depends on what is "printf" in your assembly. If it is a function pointer (aka, the address of some function is stored at the address named "printf"), then you need brackets []. If "printf" is a function, that is, if the machine code is stored at the address that your assembler calls "printf", then you must not put brackets (or else you will probably end up with a segmentation fault, as the first 32 of 64 bits of machine code of "printf" probably don't accidentally contain an address of an executable code).
I'm trying to set a break point on kernel32!LoadLibraryW or LoadLibraryA.
I'm constantly getting:
Couldn't resolve error at 'kernel32!LoadLibraryW'
My symbol path is set to: srv*https://msdl.microsoft.com/download/symbols
Any ideas on how to fix that?
Set your breakpoint in kernelbase.dll instead.
I believe WinDbg uses the symbol name and not the exported function name when resolving the address. This causes issues for some of the functions that are forwarded to ntdll.dll and kernelbase.dll.
Sometimes you can append "Stub" to the function name when setting a breakpoint and sometimes you just have to know that the function is actually implemented in a lower-level .dll and set the breakpoint on the function in that .dll. You can also find it with tab-completion and a name like *!functionname*.
I remember seeing somewhere that you can specify which dll to get the address of symbols so that one can use that variable in the watch window. I can't for the life of me remember where I saw this. The best that I can come up with is Format Specifiers in C++.
The reason I want this is so that I can see the visibility status of a window and MSVS keeps saying that identifier "IsWindowVisible" is undefined.
I was trying to use something like the following in the watch window:
::IsWindowVisible(m_hWnd),user32.dll
Using:
this->IsWindowVisible()
results in Function CWnd::IsWindowVisible has no address, possibly due to compiler optimizations. which is why I'm trying to use the win32 call. Ideas?
http://msdn.microsoft.com/en-nz/library/y2t7ahxk.aspx
Haven't tried it, but it seems to me that IsWindowVisible(m_hWnd) should work, or maybe IsWindowVisible(this->m_hWnd).
I'm currently in a Python interactive interpreter session. I have a function that I know is doing something funky, so I want to step through it in a debugger session. I know the file name and line number of the function.
Is there any way for me to now set a breakpoint in the start of that function, then run it and step through it? Without having to open an editor, locate the file, locate the function, manually insert import pdb; pdb.set_trace(), saving the file, then go back to the interpreter, reload the module the function came from and running it? Not to mention that if I forgot to remove the pdb trace that'd spell trouble later.
Summarizing the question: If I'm in a normal Python interpreter session (or iPython), is it possible to set a breakpoint somewhere and start debugging, without having to actually edit in the code pdb.set_trace() somewhere?
I can't believe I missed this, but I just glanced over the pdb documentation a second time and realized that all the run* functions do pretty much exactly what I want. They don't let me set a specific line as a breakpoint, but I can pass the function and the arguments I want to use, and it will break on the first line of the function:
import pdb
pdb.runcall(my_wonky_function, "arg1", "arg2", *myargs)
Well actually it broke at a mystical location called "EOF":
(Pdb) list
[EOF]
and I had to step twice before I got to the first line of the function, but that's hardly a problem.
Is there a way to get function caller in linux kernel? I know __func__ returns the function name which is executing. I am looking for the function which called "__func__"
You can get the caller with __builtin_return_address(0).
The caller's caller is __builtin_return_address(1) and so on.
It's a GCC extension, documented in the gcc manual: http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html
Edit: I should probably point out, that gets you the address of the caller. If you want the function name you can print it with %pS, eg:
printk("Caller is %pS\n", __builtin_return_address(0));
If you don't want to print it, you can use kallsyms_lookup() etc.
You can also print the entire call stack contents by calling dump_stack().
Whether or not frame pointers are needed depends on arch, IIRC. For x86, they are certainly desired to fully exploit these features. Also note that inlining can skew the accuracy of builtin_return_address for this very reason.
If you just want a stack dump to see how some place was reached, better use the dump_stack() function than trying to fiddle around with builtin_return_address.
To get the caller function name, one can use the below printk command.
printk("Caller is %pF\n", __builtin_return_address(0));