18

I am aware of this question, but it does not appear to work for me.

For the setup, take a simple C++ program, hw.cpp, given by: int main() { }

Upon compiling with g++ -o hw hw.cpp -O0 -g on Linux, running ldd ./hw gives:

    linux-gate.so.1 =>  (0x003e5000)
    libstdc++.so.6 => /usr/local/lib/libstdc++.so.6 (0x007c5000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x006a4000)
    libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x00a40000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00a93000)
    /lib/ld-linux.so.2 (0x00a0f000)

Now I also appear to have debug libraries in /usr/lib/debug/lib/tls/i686/cmov/, which I imagine are the corresponding debug builds of the system libraries.

Question: How do I compile my program so that it is linked against the debug builds of the standard C and/or C++ libraries, libc/libm/libstdc++, shared or static? For the shared build, I want the output of ldd ./hw to point to the debug directory.

(Background: One of the shared libraries that's used by my project is reported as leaking ("still reachable") by Valgrind, but the origins are not in the shared library itself, but in dlopen-type code (see here). So I figured that if I can step through the _Start() invocation in the CRT I might be able to trace the culprit.)

Update/Correction: I think I was just very, very stupid - the debug libraries have probably always been linked as desired all along. I was confused by the debugger not showing anything while stepping, which is because I don't have the source code for the libraries.

Update II: OK, belay the previous update. I have the library sources now, but while it is true that the standard library ships with debug symbols, I don't appear to have a separate debug build. Is such a build available, and how would I link against it?

Community
  • 1
  • 1
Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • 1
    You probably know that some standard library implementations use pools for fast allocation? http://valgrind.org/docs/manual/faq.html#faq.undeferrors – Benjamin Bannier Jan 09 '12 at 22:15
  • @honk: I'm entirely happy to accept that this is not a genuine worry. It just bothers me is that third-party code can cause warnings in *my* code (note how there are only references to some spurious `.c` files that I don't actually have, *not* to a shared library) that I can't seem to suppress... At least with a debug CRT I hope to get to take a better look. – Kerrek SB Jan 09 '12 at 22:18

2 Answers2

8

On many Linux installations the debug libraries do not contain real code; they only contain the debug info. The two are separated so that you can choose not to install them if you don't need them and you are short of disk space, but the debug libraries are no good on their own.

GDB is normally preconfigured to find the debug libraries when you need them.

Of course, your system maybe different. You don't say what it is.

ams
  • 24,923
  • 4
  • 54
  • 75
  • You're right - I did actually link against the debug libraries all along. I was thrown off by the stupidest thing, namely that I don't have the standard library *source* code - so the debugger was stepping through, but couldn't show anything! – Kerrek SB Jan 10 '12 at 13:42
  • Actually that doesn't help after all - I don't just want the debug symbols, but an actual debug *build* of the library. Is this available on Debian/Ubuntu? – Kerrek SB Jan 10 '12 at 18:37
  • Not usually. You're absolutely right that the normal optimized libraries are a problem if you want to step through the library code. Of course, if it's just a specific library you want, then you can always re-build it yourself. `sudo apt-get build-dep package-name` will install whatever you need to do the build, and the source packages themselves can be downloaded with `apt-get source package-name`. – ams Jan 11 '12 at 09:45
  • I can get the source, as `eglibc-source`, but then how would I link against it so that I don't use the standard libraries by accident? Something with `-nostdlib`? – Kerrek SB Jan 11 '12 at 11:50
  • Assuming you're using the dynamic libraries, you probably don't need to relink at all. Just do `export LD_PRELOAD=/path/to/debug/libc.so.6` and then *any* programs you run from that shell will use the debug library. – ams Jan 11 '12 at 11:57
  • `LD_LIBRARY_PATH` might also do the job, but for all glibc libs. – ams Jan 11 '12 at 11:59
  • What about the CRT, though? The `crt1.o` or whatever it is called... that's always linked statically, isn't it? Is there a way to also get the debug version of that one? – Kerrek SB Jan 11 '12 at 12:00
  • The isn't a debug version of crt1.o; that's written in assembler. – ams Jan 11 '12 at 16:04
0

Your program gets linked to debug libs.

Only the 'ldd ./hw' is finding the libstdc++ in standard location. For that you need to change LD_LIBRARY_PATH to get the debug shared libraries to load and ldd to find them properly.

Rajendran T
  • 1,513
  • 10
  • 15
  • That too doesn't work for me. I've tried several variations of setting that variable, but `ldd` doesn't change. I know that setting `LD_LIBRARY_PATH` does work that way, as it works well with other (non-system) libraries... or are you saying that `ldd` will *never* report the debug library? – Kerrek SB Jan 09 '12 at 22:21
  • @KerrekSB: Did you try (assuming bash): `LD_LIBRARY_PATH=/usr/lib/debug/lib/tls/i686/cmov/ ldd ./hw` – Martin York Jan 09 '12 at 23:05