bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Martin Percossi
Subject: Issues with gdb under linux....LOTS of them
Date: Thu, 20 Sep 2001 18:01:37 +0100

Hi, I've been using dbx for a while under solaris and it's worked fine.
I've recently attempted to make a switch to gdb running under linux. 

Basically nothing works. Nothing. First of all, some version info:

GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux".

The machine is running RedHat Linux 6.2. Running dmesg yields the
following output:

Linux version 2.2.16-3cc (address@hidden) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #3 Tue Apr 3 17:23:51 CDT 2001
Warning only 896MB will be used.
Detected 860946 kHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1717.04 BogoMIPS
Memory: 906004k/917504k available (1084k kernel code, 420k reserved,
9476k data, 64k init, 0k bigmem)
Dentry hash table entries: 262144 (order 9, 2048k)
Buffer cache hash table entries: 524288 (order 9, 2048k)
Page cache hash table entries: 262144 (order 8, 1024k)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: Intel Pentium III (Coppermine) stepping 03
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch (address@hidden)
PCI: PCI BIOS revision 2.10 entry at 0xfc7ae
.
.
.

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.
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! 
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.

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 fact, the only way I can get any information about the object at all
is to print it's contents, i.e. if we have MyClass *x;    , I have to
write: print *x. I then see the contents of x. Trying to run ANY method
of x gives the above mentioned problem.

Basically, these problems make debugging virtually impossible. I thought
gdb is supposed to be good. I was sure it would be better than dbx (just
having command completion is a big bonus). But if it can't deal with
multi-threaded applications and simple c++, and if it can't find files
that definitely exist...... no it can't be? Surely I'm doing something
idiotic?

Please someone tell me I'm doing something idiotic.


-- 
Martin Percossi
Development
RiverSoft Ltd.
address@hidden
Tel. 020 8392 5740 Ext. 5724

Email disclaimer
The information in this email is confidential and may be legally
privileged.
It is intended solely for the addressee. Access to this email by anyone
else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance
of it, is prohibited and may be unlawful.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]