I have printed the address of the function in U-boot by adding the following print.
printf("initcall: %pS \n", (char *)*init_fnc_ptr - reloc_ofs);
Following line printed by adding debug prints. Is there anyway to know the function name from the function address.
initcall: 80809c05
When building U-Boot a file u-boot.map is written. You can look up the the addresses of the functions (before relocation) there.
Related
I am reversing a MIPS .cgi with ghidra which has an external function call. I opened that library file to view the function decompilation and it was using the open() function with a hex value instead of path... How can I resolve that value to an exact path or a location in memory or something?
The exact line from ghidra:
local_10=open((char *)0x2060,0)
(char*)0x2060 is a pointer to memory address 0x2060. The first letter of the string should located there.
I am working on a small IDAPython script.
The script itself works 100% of the time on lines like this:
qword_FFFFFFF006F1E6C0 DCQ 0xFFFFFFF007758C18
As it looks into address 0xFFFF.. sees if there's a function there, and if there is, renames the qword with the function name + segment info.
Now, sometimes, the disassembly looks like this:
off_FFFFFFF006F1E690 DCQ OSDictionary::withCapacity(uint) , and of course, the script breaks down here (expects an address, is given a name..).
What I'd like to do is to get the address of the second operand (OSDictionary::with...), and execute the script as normal.
Unfortunately, I have no idea how to do that, as to get the address I use this:
disas = GetDisasm(addr).split(" ")
fun_addr = disas[1]
....
If you always want the address of the destination, you could use get_qword function
https://www.hex-rays.com/products/ida/support/idadoc/1321.shtml
Which is the Qword function in IDAPython.
Simply do Qword(addr), this will give you the address as a number.
You might need to compensate for endianity (use struct).
i write a code for tcp connection in c language, and in some place i added two perrors:
perror("FAIL1: ...");
perror("FAIL2: ...");
and the output is:
FAIL1: ..: Success FAIL2: ..: Invalid argument
Just want to understand - what does it mean the "Success"? TNX!
Take a look at the man page below.
http://man7.org/linux/man-pages/man3/perror.3.html
The first two paragraphs have the content you need.
Essentially the string representation of "errno" a global variable is printed out along with your arguments. If you have no errors (errono = 0). This is causing your program to print "SUCCESS".
Is it possible to run code inside gdb? For example, if I were debugging a .c file, and I wanted to get the strlen() of a character array at a particular point in time, I can't just type in strlen(str) into the buffer - it is an invalid command. What can I do?
From gdb prompt call strlen(the_char_array). Eg.,
(gdb) call strlen(the_char_array)
I have a function that pretty prints a data structure, its function prototype is:
void print_mode(FILE *fp, Mode *mode);
the FILE* allows you to redirect the output to anywhere you want, e.g. stdout, stderr, a file etc. Mode is the data structure
I am trying to call this function from within gdb and want the output to be directed to the gdb console window, stdout?
I have tried:
(gdb) p print_mode(STDOUT,fragment_mode)
No symbol "STDOUT" in current context.
(gdb) p print_mode(stdout,fragment_mode)
$17 = void
neither of which work
any ideas how i can get the output of the function to display in the gdb console?
should add - I am using gdb within emacs 24.2.1 under linux
STDOUT seems to be macro, which is not know to GDB, as handled prior to compilation by the pre-preprocessor.
Using stdout should do the job.
However the function print_mode() simply does not seem to print out anything.
In terms what's being printed to the console by the program being debugged, GDB's commands printand call should not make a difference.
For details on this you might like to read here: https://sourceware.org/gdb/onlinedocs/gdb/Calling.html
An issue might be that stdout by default is line buffered, so output would not occur before detecting a linefeed and print_mode() perhaps does not send a linefeed (\n).
To test this just use stderr as output file, as the latter isn't buffered:
p print_mode(stderr, fragment_mode)
Oh dear - silly mistake. You're right, stdout does do the job.
I forgot that having upgraded from emacs 23 to 24, the way gdb works has changed in as much as it now opens a separate buffer *input/output of program-name* to which it redirects the output of the program being debugged. In the prior version of emacs it was all displayed in the same, single gdb buffer.
So my second attempt was actually working, I was just looking in the wrong place so didn't see the output