Archive for November, 2005

Non-java developers unite!

Wednesday, November 16th, 2005

Someone sent around a great headline at Infoworld

Importing debug information into dbx

Monday, November 14th, 2005

I’m sure I wrote this up somewhere before, but now I can’t find it. Just in case you guys (my two faithful readers) haven’t seen this trick yet. If you are stuck with a core file that doesn’t have debug information, you can “import” debugging information using the “loadobject -load” command. It’s especially useful for C++ to help get rid of the mangled names that show up in stack traces.

% #########################
% more t.c

#include "t.h"

struct foo foofoo;

int
main()
{
    foofoo.a = 1;
    foofoo.b = 2;
    * (int *) 0 = 0;
}

% #########################
% more t.h

struct foo {
int a;
int b;
};

% #########################
% cc -o t t.c # no debug info

% #########################
% ./t
Segmentation Fault (core dumped)

% #########################
% dbx t core
Reading t
core file header read successfully
Reading ld.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x00010bb4: main+0x001c:   clr      [0]
(dbx) whatis foofoo
dbx: warning: unknown language, 'c' assumed
(int {assumed}) foofoo;
(dbx) print foofoo
foofoo = 0x1
(dbx) whatis -t foo
dbx: "foo" is not defined in the scope `t`main`
dbx: see `help scope' for details
(dbx) quit

% # 
% #  You really want to see the contents of the 'foofoo'
% #  structure, but the binary doesn't have debug info!
% #  So create a dummy .so file with debug info, and load
% #  that into dbx manually.
% # 

% #########################
% more dummy.c

#include "t.h"

% #########################
% cc -G -g -o dummy.so dummy.c

% #########################
% dbx t core
Reading t
core file header read successfully
Reading ld.so.1
Reading libc.so.1
Reading libdl.so.1
Reading libc_psr.so.1
program terminated by signal SEGV (no mapping at the fault address)
0x00010bb4: main+0x001c:   clr      [0]
(dbx) loadobject -load dummy.so
Reading dummy.so
Loaded loadobject: /set/dbx/somewhere/misc/coretest/dummy.so
(dbx) modules | grep dummy
Not Read  dummy.o
(dbx) module dummy.o
Read      dummy.o
(dbx) whatis -t foo
struct foo {
    int a;
    int b;
};
(dbx) print *(struct foo*)&foofoo
dbx: warning: unknown language, 'c' assumed
*((struct foo *) &foofoo) = {
    a = 0x1
    b = 0x2
}

Linux Compilers require a glibc fix (headers)

Friday, November 11th, 2005

There is a glibc bug that makes our new C Compiler on Linux not work. The symptom looks like this:

> "helloworld.c", line 8: internal compiler error: DBGGEN ERROR:
> FILE="../src/dbg_libdwarf.c", LINE=46, Could not load dwarf library:
> libdwarf.so : libdwarf.so: cannot open shared object file: No such file
> or directory [DBG_GEN 5.0.8]
> cc: acomp failed for helloworld.c

The way to fix it on SuSE Linux Enterprise 9 (our primary tested version of SuSE) is to use this patch. But now we have someone asking how to fix that in SuSE 9.1? Now I’m at the limits of my Linux experience. Here are my questions:

  • How do I find out what version of glibc is installed?
  • How do I find out which version of glibc got a specific fix?

I know I can use rpm -qf to find out which SuSE package is installed and contains /lib/libc.so.XX But that doesn’t give me the glibc version (like 2.3.3 or whatever). The bug I’m looking at is described as “Bug 47950” in the SuSE SLES9 docs. Is that a novell-specific bug tracking system? Technorati tags :