Could not load shared library symbols for linux-vdso.so.1. while debugging

Question

Not loading VDSO.so is one of the famous bugs you encounter while using gdb and glibc >2.2. I found that was planned to get repaired in gdb 7.5.1, but it wasn\'t. Okay I f

Answer 1

For anyone who (like me) just wants gdb to shut up about missing symbols, try adding this to your ~/.gdbinit (but see caveats below):

set logging redirect on
set logging file /dev/null
python
def on_new_objfile(e):
    gdb.execute("set logging off")
    #print "new objfile:",e.new_objfile.filename
    if e.new_objfile.filename[:19] == "system-supplied DSO":
        gdb.execute("set logging on") # hide inevitable error message
gdb.events.new_objfile.connect(on_new_objfile)
end

Caveats:

• Monopolizes the set logging interface; if you want to use logging you'll need to change it to save the previous logging settings.
• Hard-codes "system-supplied DSO"; might be brittle wrt new kernel or gdb versions.
• It assumes at least one objfile will be loaded after vdso to reenable output; I'd be very interested if anyone with better gdb internals knowledge could point out the actual after-symbol-load-has-failed hook, since for now it risks leaving output disabled when the program starts if vdso is the last objfile loaded.

Answer 2

Not loading VDSO.so is one of the famous bugs you encounter while using gdb and glibc >2.2.

No, it's not. The problem here is simply a useless warning, which you can safely ignore.

I found a work-around here Here, but I didn't understand it so how to apply it.

You didn't find a "workaround". You found a patch to GDB, which disables the warning.

To apply it, use the patch command, and then build your own GDB. But it is much simpler to just ignore the warning in the first place.