set sysroot

set sysroot command

Specifies the local directory that contains copies of target libraries in the corresponding subdirectories. This option is useful when debugging with gdbserver.

Syntax

set sysroot [Directory]
set sysroot remote:/
set sysroot remote:[Remote directory]
set solib-absolute-prefix [Directory]
show sysroot

Parameters

Directory Specifies the local directory that contains target libraries in the subdirectories corresponding to target paths. E.g. if you set this to c:\sysroot, GDB will expect to find a copy of /lib/ld-linux.so inc:\sysroot\lib\ld-linux.so. Remote Directory Specifies the directory on the remote machine that contains the libraries. Normally the Remote Directory should simply be '/'

Typical use

This command is useful when debugging remote programs via gdbserver and the libraries on the target machine (running gdbserver) do not match the libraries on the source machine (running gdb). In order to set breakpoints and find source lines that correspond to different code locations GDB needs to access the library files containing symbol information. Copying those libraries to locations under a local directory and specifying its path via set sysroot allows GDB find them.

Default value

The default value for the set sysroot variable depends on your toolchain. If your GDB binary was compiled with the --sysroot argument, you won't need to run the set sysroot command - the sysroot will be automatically set to the location specified during compilation. Otherwise the default value will be "" and you might need to set it manually if you are debugging remote processes.

Examples

In this example we will debug a simple shared library with gdbserver:

#include 

int func()
{
    printf("In func()\n");
    return 0;
}

We will use a simple program to test our library:

#include 

int func();

int main()
{
    printf("In main()\n");
    func();
    return 0;
}

First, we build the application and the library and deploy it to another machine:

cd /home/testuser/libtest
g++ -ggdb -fPIC -shared lib.cpp -o libTest.so
g++ -ggdb main.cpp libTest.so -o testApp -Wl,--rpath='$ORIGIN'
scp testApp libTest.so deploy_machine:/tmp

Second, we create a local sysroot directory that will contain copies of system libraries from the target machine:

mkdir /home/testuser/libtest/sysroot
cd /home/testuser/libtest/sysroot
scp -r deploy_machine:/lib lib

Third, we move the libTest.so library to the directory in sysroot that corresponds to /tmp on the target machine (where we have deployed our library):

mkdir tmp
mv ../libTest.so tmp

Then we run gdbserver on the deploy_machine machine:

cd /tmp
gdbserver :2000 testApp

Finally we run GDB:

cd /home/testuser/libtest
gdb testApp

Note how after we issue the set sysroot command, GDB will read all the symbols from the copied DLLs inside the /home/testuser/libtest/sysroot.

GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<
Reading symbols from /home/testuser/libtest/testApp...done.
(gdb) set sysroot /home/testuser/libtest/sysroot
(gdb) break main
Breakpoint 1 at 0x80484ed: file main.cpp, line 13.
(gdb) target remote deploy_host:2000
Remote debugging using deploy_host:2000
Reading symbols from /home/testuser/libtest/sysroot/lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /home/testuser/libtest/sysroot/lib/ld-linux.so.2
0x0012d0e0 in ?? () from /home/testuser/libtest/sysroot/lib/ld-linux.so.2
(gdb) continue
Continuing.
Breakpoint 1, main () at main.cpp:13
13 printf("In main()\n");
(gdb) info shared
From To Syms Read Shared Object Library
0x0012c830 0x001435cf Yes (*) /home/testuser/libtest/sysroot/lib/ld-linux.so.2
0x009563a0 0x009564c8 Yes /home/testuser/libtest/sysroot/tmp/libTest.so
0x007ecbe0 0x008f9784 Yes (*) /home/testuser/libtest/sysroot/lib/i386-linux-gnu/libc.so.6
(*): Shared library is missing debugging information.
(gdb) break func
Breakpoint 2 at 0x95646e: file lib.cpp, line 9.
(gdb) continue
Continuing.
Breakpoint 2, func () at lib.cpp:9
9 printf("In func()\n");
(gdb) continue
Continuing.
[Inferior 1 (process 11111) exited normally]
(gdb) quit

We could also have avoided copying libraries manually. If you specify remote:/ as the sysroot, GDB will download the libraries automatically:

GNU gdb (Ubuntu/Linaro 7.4-2012.02-0ubuntu2) 7.4-2012.02
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<
Reading symbols from /home/testuser/libtest/testApp...done.
(gdb) set sysroot remote:/
(gdb) break main
Breakpoint 1 at 0x80484ed: file main.cpp, line 13.
(gdb) target remote deploy_host:2000
Remote debugging using deploy_host:2000
Reading symbols from remote:/lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for remote:/lib/ld-linux.so.2
0x001cb0e0 in ?? () from remote:/lib/ld-linux.so.2
(gdb) continue
Continuing.
Breakpoint 1, main () at main.cpp:13
13 printf("In main()\n");
(gdb) info shared
From To Syms Read Shared Object Library
0x001ca830 0x001e15cf Yes (*) remote:/lib/ld-linux.so.2
0x009d93a0 0x009d94c8 Yes remote:/tmp/libTest.so
0x004f7be0 0x00604784 Yes (*) remote:/lib/i386-linux-gnu/libc.so.6
(*): Shared library is missing debugging information.
(gdb) break func
Breakpoint 2 at 0x9d946e: file lib.cpp, line 9.
(gdb) continue
Continuing.
Breakpoint 2, func () at lib.cpp:9
9 printf("In func()\n");
(gdb) continue
Continuing.
[Inferior 1 (process 11124) exited normally]
(gdb) quit

Compatibility with VisualGDB

Cross-compilation toolchains provided with VisualGDB are configured to use correct sysroot. If you want to override this behavior you can specify the set sysroot command in the GDB Startup commands in VisualGDB Project Properties.