0

I'm developing a shared library for Linux that spawns some threads I want to label in the debugger.

I've read this can be done by writing to /proc/[PID]/tasks/[TID]/comm, but this isn't working (I'm targeting an older libc). I also want to be able to assign names longer than the comm limit.

My plan was to auto-load a Python script to do this by placing it in the .debug_gdb_scripts section.

However I want to strip debug information besides the script and what it needs. I've tried using the --keep-symbol option but all of the debug sections (include .debug_gdb_scripts) are still removed.

Is there some way to keep these?

Matt
  • 865
  • 2
  • 10
  • 16

1 Answers1

2

One idea that comes to mind is to strip your program first, and then add the .debug_gdb_scripts afterwards, using objcopy.

Another way might be to put .debug_gdb_scripts inside the mini debug section. I think this should work ok, though it is a bit weird -- I think the first approach is more sound.

Yet another option is to just do the standard thing and strip all the debuginfo to a separate debuginfo file, which you would then use when debugging. However from your question I assume there is some reason you don't want to do this.

Tom Tromey
  • 21,507
  • 2
  • 45
  • 63
  • I want to distribute a shared library where users can set breakpoints and print argument information on a few functions but strip symbol/debug info for everything else. It sounds like that may be impossible. – Matt Jul 30 '15 at 17:22
  • It's definitely difficult, I think, because you'd want to ship the DWARF for the types and some info for those functions but not for others. – Tom Tromey Jul 30 '15 at 17:49