gdb 'call' returns negative value - c++

I am trying to load a shared library in gdb and invoke entry function call from gdb.
For example mylib.so has mylibraryEntryPoint() function.
However, I am getting a negative output. I am curious what does this error code mean.
(gdb) sharedlibrary /usr/home/mylib.so
Symbols already loaded for /usr/home/mylib.so
(gdb) call mylibraryEntryPoint()
$9 = -2048550400 // Here is the problem.
The strange part is this function call works on another Linux VM with same gdb version.
I am expecting the function to be 'executed' on this machine. (It prints some lines as well). Since it is returning the negative value which is not really returned by my function, it is an error code of gdb. It tells gdb was unable to run the function.

Related

GDB says 'No symbol "putenv" in current context'. But this is a libc function, right?

I'm using gdb to attach to a program that's already running (ruby).
Strangely, when I try to execute call putenv (...) in gdb, it tells me 'No symbol "putenv" in current context.'
putenv is a libc function, right? Is there a way for me to get this into the current context? Flailingly, I've tried running file /usr/lib/x86_64-linux-gnu/libc.so, but this results in '...not in executable format: file format not recognized'.

call dlopen from gdb

I want to load shared library (.so) from gdb, I found this command :
(gdb) call dlopen("path/to/lib.so",..)
But it doesn't work, I link my program with -ldl.
The error I get is:
No symbol "dlopen" in current context
what did I miss ?
I found a command that resolve the half of this topic. I explain:
First, you should load the shared object into the process:
(gdb) set environment LD_PRELOAD /usr/lib/libdl.so
After that, we define the file to debbuging
(gdb) file pgm
For testing, we put breakpoint in main i.e
(gdb) break main
Now, we run the program
(gdb) run
and we call dlopen
(gdb) call dlopen("/path/to/lib.so",2)
until now it's work, but when I put the last command, I have:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7de7f09 in ?? () from /lib64/ld-linux-x86-64.so.2
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(_gdb_expr) will be abandoned.
When the function is done executing, GDB will silently stop.
nothing changes when I modify 'unwindonsignal to (on/off)'
What did I forget this time ?
useful

Set breakpoint in gdb on array out of bounds for gfortran program

I have a Fortran program compiled with gfortran with the -fcheck=bounds compiler option. This causes the code to report "array out of bounds" errors and subsequently exit.
I would like to debug my program using gdb to find the cause of the error. Unfortunately in gdb the code will still just exit on an out of bounds error.
Is there a way to tell gdb to stop execution when an out of bounds error occurs?
Compile with -g to get debugging information. Then, first, I placed a break point on exit, this works fine, once the program stops you'll be able to backtrace from exit to the point of the error.
The backtrace also passes through a function called _gfortran_runtime_error_at, so you might have more luck placing the breakpoint there, this worked for me, and obviously will only trigger when you get a run time error.
To set a breakpoint on gdb, use the command break then the name of the file you are debugging, a colon and the number of the line from which you want to break execution :
break main.f90:24
will stop the execution at line 24 of program main. Then you can use the step command to jump to the next line and so on. At this point you can use print to check the value of any variable you want. If you have defined another breakpoint, you can use the command next to jump to the next breakpoint directly.
You will need to compile your program with the -g flag to be able tu use gdb

How to set breakpoint with gdb on function from stripped shared library?

I've got an executable file and stripped lib.so file that is used by executable.
I have decompiled lib.so file and defined the function fun I want to set breakpoint and its internal address.
Is it possible to set breakpoint on function fun using gdb?
How to define the address of fun at runtime?
Is it possible to set breakpoint on function fun using gdb?
Yes: GDB can set a breakpoint on arbitrary address:
(gdb) break *0x12345678
How to define the address of fun at runtime?
Since GDB by default disables ASLR, the address of fun will not change from run to run (assuming you run the program under GDB from the start).
Therefore, you only need to find the address of fun once.
Let's assume that your lib.so is linked at 0 (most non-prelinked shared libraries are).
Further let's assume that you are on Linux.
Then info proc map will tell you where the lib.so is loaded (you want the first start address belonging to it). Add that start address to the value of fun you found by disassembling, and set a breakpoint there.

nm versus gdb break

I am working on Ubuntu 14.04 LTS.
I have an executable file exec compiled from file.c. The file.c makes use of functions from a static library. For example, let's says that fubar() is a function of the static library that is used in file.c.
This is something that I have noticed.
nm exec | grep fubar gives a certain value.
(on my system and for my executable, 0808377f)
gdb ./exec and then break fubar gives a different value.
(on my system and for my executable, 0x8083785)
When I do a similar thing for another executable file (exec1 compiled from file1.c, it outputs the same value for both the commands).
Both the commands are supposed to output the same virtual address. Aren't they? I am obviously missing something. Can someone explain what exactly is happening? And what is the difference between both the commands.
Barring unusual things like -fPIE, what is going on here is that the gdb command break function actually means "break after the function prologue for function". This way, arguments are set up properly by the time the breakpoint is hit.
If you want to break exactly at the first instruction of a function, use the * syntax, like:
(gdb) break *function
If you do this the addresses will probably match.