Selectively loading symbols

[BitFlipper]

Hi,

I’m using VisualGDB Custom Edition 5.4R12, and have some issues with symbols being loaded that severely slow down debugging. I can’t figure how to have better control over which libraries should have symbols loaded and which not.

What I’m doing is debugging a C++ library that uses Boost.Python, and this library is loaded as part of running a Python script. Everything “works” in the sense that I can set breakpoints etc and they are hit, after which I can step through the C++ code etc. However some of the Python libraries, and specifically “/usr/lib64/libboost_python35…” and “/usr/lib64/libboost_regex…” load extremely slow. It takes minutes for those to load and I really don’t need any symbols from them at all. Please note that I cannot change any of those libraries, e.g. to use stripped versions. So I’m stuck with those.

I need some way to tell GDB not to load the symbols for those files at all, but so far everything I’ve tried seems to be everything or nothing, i.e. either everything gets loaded (really slow), or nothing gets loaded (no breakpoints hit).

It seems like a catch-22… I can do set auto-solib-add off however then it never stops so that I can do the required sharedLibrary mylib in order to actually load my libraries.

The things I have tried, and the results:

1. set auto-solib-add off
   Result: The program just runs end-to-end and exits without allowing me a chance to use sharedLibrary.
2. set sysroot <invalid dir>
   Result: The slow libs are not loaded, however once again none of my breakpoints are hit. I tried all variations of adding set solib-search-path <mylib path>, set debug-file-directory <mylib path>
3. Using sharedLibrary <mylib> in the “Additional GDB Commands” sections.
   Result: GDB error: “No loaded shared libraries match the pattern …”. So it has to be loaded first? Catch-22.
4. Writing a Python GDB extension script to explicitly call sharedLibrary <mylib> after a stop event.
   Result: The stop event is not called at the right places, and so far I’ve had no luck with this.
5. Following the instructions here that says: “Normally you can control symbol loading using the Modules and the Call Stack windows in Visual Studio”.
   Result: This doesn’t seem to have any effect whatsoever, no matter how many times I select that the problematic modules not be auto loaded. TBH I don’t understand the statement “Normally you can control symbol loading using the Modules and the Call Stack windows in Visual Studio”. Does this mean it can actually control which modules GDB is supposed to load symbols for and which not?

Any advice would be appreciated,
Thanks!

• This topic was modified 5 years, 1 month ago by BitFlipper.

[support]

No problem, we can suggest a few tricks:

1. You can always simply hardcode a breakpoint in the code (asm(“int3”) for x86 or asm(“bkpt 255”) for ARM). This will stop gdb once the corresponding piece of code is executed regardless of the symbol load status.
2. Alternatively, setting breakpoint in your function by its name (via Debug->Windows->Breakpoints->Add) may work even without loading symbols (ELF symbol tables are separate from DWARF symbols), although it depends on the gdb internals and we have not explicitly tested this assumption.
3. If you could share a detailed gdb log (with timings) from a session showing slow symbol loads, we might be able to add logic for detecting slowly loading symbols and displaying some GUI allowing to stop them from auto-loading.
4. Finally, you can try using gdb index files to speed up symbol loading. We are currently looking into managing index files automatically and would appreciate your feedback on real-world project performance difference with/without using those files.

[BitFlipper]

Thanks for the quick reply! For each of the suggested tricks:

1. I did a quick test of the asm break, and that works and is very fast after first doing set auto-solib-add off. After it hits the breakpoint, I can then do sharedLibrary on the libs I care about (which also loads quite fast).
   I’m wondering if I can automate this. For instance, if I put the asm break somewhere early on in my executable (let’s say in its startup code), then have a Python script that responds to that break. It then does gdb.execute(“sharedLibray <mylibs>”) and continues. So it is basically transparent.
2. I tried setting a breakpoint using the function name but I could not get it to work.
3. Where can I send a log file? I don’t want to post it here publicly. It would be great if VGDB allowed you to create a whitelist/blacklist that can be used to control symbol loading. I’m surprised it is so hard to do with GDB, or maybe I’m just missing something.
4. Previously I was looking into GDB index files a bit to see if that could help. But the above asm break seems the best short term solution, so I’ll try to make that work.

Thanks for your support!

[BitFlipper]

So the asm break turns out to be not so useful as I ran into all sorts of weird problems. I have another solution that is mostly working now, except for one non-critical but annoying issue. Maybe you have some insight on how to fix that last issue. What I have is:

Do:

set auto-solib-add off
handle SIGUSR1 stop noprint nopass

 

Somewhere in my code, do:

  raise(SIGUSR1);

 

Have an external GDB command file containing something like this:

catch signal SIGUSR1
commands
echo Now handling SIGUSR1
sharedLibrary myLib1.so
sharedLibrary myLib2.so
end

 

Add the following to “Additional GDB Commands”:

source /path/to/gdb_cmd_file

The above works and is quite fast to start up. But the remaining issue is that it breaks and stops on the raise(SIGUSR1); I guess that is to be expected. However I would like to just let it continue automatically after it handled the SIGUSR1. So when I then add the following continue to the commands in the file:

handle SIGUSR1 stop noprint nopass
catch signal SIGUSR1
commands
echo Now handling SIGUSR1
sharedLibrary myLib1.so
sharedLibrary myLib2.so
continue
end

 

…it causes VS to lock up, although I can see the program ran successfully and exited. At that point I need to force kill VS. I think VGDB still thinks the program is stopped, although it ran to completion.

Any suggestions on how to get it to work?

Thanks for you help!

• This reply was modified 5 years, 1 month ago by BitFlipper.
• This reply was modified 5 years, 1 month ago by BitFlipper.

[support]

Sorry for the delay. Please feel free to send the log file to support@sysprogs.com.

Unfortunately the SIGUSR1 workaround will not work when using an IDE like VisualGDB because the following events will take place:

1. GDB will catch SIGUSR1 and report to VisualGDB that the session is stopped.
2. VisualGDB will issue the regular status querying commands (e.g. will query the backtrace and register contents).
3. GDB will immediately resume execution per your custom “catch” handler and will ignore the commands issued by VisualGDB.
4. VisualGDB will wait until the time-out specified in the settings and will then show the “GDB not responding” overlay.

We should be able to modify VisualGDB to selectively load the symbols as fast as the current setup (it will use the set stop-on-solib-events command and will then issue symbol load commands based on the library whitelist), however we would need to see that log in order to make sure we can make the new logic easily discoverable for all users.

[support]

Hi,

Just wanted to let you know that we have added full support for specifying which symbols get loaded automatically for Linux projects in the following build: VisualGDB-5.5.1.3322.msi

You can configure it via the Debug Symbols page of VisualGDB Project Properties:

Attachments:

You must be logged in to view attached files.

[BitFlipper]

Hi,

This works great, thanks for adding this feature so quickly! I like that it auto-populates with all loaded symbol files. This makes it really easy to select just the needed ones. The time displayed to load each file is also a great help!

Thanks again!

[Author]

Posts