Re: Issues with gdb under linux....LOTS of them

[Jim Blandy]

Martin Percossi <address@hidden> writes:
> Please someone tell me I'm doing something idiotic.

No, not at all; you're just laboring under a common misunderstanding.

This list doesn't provide free technical support.  If your GDB came
with a Linux distribution you bought from a company, you should
contact that company for support.  Despite the mailing list address,
this is not Red Hat's technical support line for GDB.  I think Red Hat
usually only provides installation support anyway, and only to the
original purchaser of the distribution.

GDB is maintained entirely by volunteers.  Some of us do it in our
spare time.  Others are lucky enough to have employers who pay us to
work on GDB; but we work on what our customers pay us to.  If you
don't have a contract with someone, there's nobody you can complain
to.

The upside is that you have the sources yourself, so if you have the
time and the skill, you can fix the problem yourself.  I personally
would be very excited to see patches for GDB's C++ woes --- assuming
they are clean and well-written.

So, in fact, this list is the opposite of a technical support line:
it's meant to help GDB's users contribute to GDB!

I strongly encourage you to become a volunteer, and contribute fixes
to GDB for the problems that bother you.  Or, you can hire someone
else to fix the problem for you.  Those are the only ways things get
done.

To get to your specific questions:

> The following things won't work:
> 1) using: set editing-mode vi
> to get vi style commands doesn't work. Nor does M-C-j to do the
> same.

I don't think GDB supports a `set editing-mode' command.  I can't find
it in the on-line help, or in the manual.  I'm looking at the current
sources, available from http://sources.redhat.com/gdb.

M-C-j works fine for me.  Can you be more specific about the problem?

> 2) setting breakpoint for a method in a shared library doesn't seem to
> work. Strange, because it seems some of the symbols from other shared
> libraries are loaded (I see them when I press tab). Even when I fully
> qualify using 'filename'::class::method or even 'filename'::line_number.
> The filename is of form CMyFile.cc. It says the source file is not
> found. So I qualify the directory, i.e. '/x/y/z/CMyFile.cc':122 and it
> STILL can't find the file. How is this possible? The file _certainly_
> exits! 

There are two possible problems:

First:

GDB doesn't read symbols from shared libraries until they are actually
loaded by your program.  This is a bug, but fixing it properly
requires some support from the dynamic linker which we don't have at
the moment.

The workaround is to set a breakpoint in main, and start your
program.  By the time your program enters main, the dynamic linker has
loaded the shared libraries your program uses, and GDB should have
read their symbols.

You may see some of the shared library's symbols listed --- those are
the symbols your program calls directly.  Your executable contains
program lookup table entries for them, so they appear in GDB's minimal
symbol table.

Second:

I have heard of problems setting breakpoints in methods having to do
with confusion involving linkonce sections.  If you could provide us
with a test case we can use to reproduce the problem, that would be
a helpful contribution.


> 3) I've already mentioned this in another message, but I'll repeat,
> pressing Ctrl-c once the program is running suspends execution. It
> should be resumed using c <RET>. (ie. command "continue"). This only
> resumes execution for a single thread, and the applicatioin is highly
> multi-threaded, making this feature quite unusable. Example output:
> 
> Continuing.
> [Switching to Thread 23940]
> 
> Program received signal SIGINT, Interrupt.
> 0x40970dcb in __sigsuspend (set=0xbedffc78) at
> ../sysdeps/unix/sysv/linux/sigsuspend.c:48
> 48      in ../sysdeps/unix/sysv/linux/sigsuspend.c
> 
> Using thread apply all continue yields following output:
> .
> .
> .
> Thread 23 (Thread 23999):
> Continuing.
> ptrace in stop_thread: Operation not permitted.
> 0x40970dcb      48      in ../sysdeps/unix/sysv/linux/sigsuspend.c
> (gdb) c 
> Continuing.
> ptrace in stop_thread: Operation not permitted.
> (gdb) c
> Continuing.
> warning: Couldn't get registers
> warning: Couldn't get registers
> warning: Couldn't get registers
> Error accessing memory address 0x406398c0: No such process.
> warning: Couldn't get registers
> Error accessing memory address 0x406398c0: No such process.

Have you tried the current GDB sources?  I'm not sure, but I think
people have been working on the thread handling since 5.0.

> 4) When I finally do manage to get a breakpoint working, I try to run a
> method on an actual parameter for the method I have just stopped at: but
> I get:
> 
> Cannot resolve method CMyClas::MyMethod to any overloaded instance

In general, GDB's C++ support is very poor.  I'm sorry about that.
Patches are welcome.