Re: Problem of GDB interaction with interrupted system calls
Sorry. I cannot agree with it. It make GDB not flexible. Hui On Fri, Nov 13, 2009 at 22:42, Alexandre Rusev aru...@ru.mvista.com wrote: teawater wrote: I think this is a hehavior of kernel. I think change pc always a danger thing. :) Yes, extremely dangeorous! ;) But GDB supports feature such as call func_name, when using it the Joe user does not even cares the PC, he just thinks that he makes call to some function... Moreover the intent of changing stack by kernel is to make system call to restart. The kernel (in theory) could choose to not return to userland at this point (because of no signal handlers are set by the process) and restart syscall internally. If it where so, all the process could have been transparent for GDB. And this usecase is enounted quite often by users:( Because the nature of the problem is quite clear, it could be (once in theory) worked around both in kernel and in GDB. Because the GDB does a lot of tricks and serves to thecnical puroses may be it it the best place to implement workaround there? Yet from point of view of kernel that's the place where either nobody (even GDB) is supposed to intervien the kernel internal housekeeping, at least till the next machine instruction is executed. So the kernel could either: [1] not enable the GDB/ptrace to stop process and change user registers at that point [2] remember the state of essential registers (PC, may be others likes FP) and revert all changes before executing the next instruction [3] remember the state of essential registers (PC, may be others likes FP) and if the process was stopped and somebody (GDB/ptrace) changed PC before execution of the next instruction then kernel can avoid it's own changes of PC Anyway the problem exists and I'm trying at least to find out where needs to be fixed infrun: clear_proceed_status_thread (process 4542) infrun: proceed (addr=0x, signal=144, step=0) infrun: resume (step=0, signal=0), trap_expected=0 infrun: wait_for_inferior (treat_exec_as_sigtrap=0) infrun: target_wait (-1, status) = infrun: 4542 [process 4542], infrun: status-kind = stopped, signal = SIGINT infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0xb7fe3410 infrun: random signal 2 Program received signal SIGINT, Interrupt. infrun: stop_stepping 0xb7fe3410 in __kernel_vsyscall () (gdb) disas Dump of assembler code for function __kernel_vsyscall: 0xb7fe3400 +0: push %ecx 0xb7fe3401 +1: push %edx 0xb7fe3402 +2: push %ebp 0xb7fe3403 +3: mov%esp,%ebp 0xb7fe3405 +5: sysenter 0xb7fe3407 +7: nop 0xb7fe3408 +8: nop 0xb7fe3409 +9: nop 0xb7fe340a +10: nop 0xb7fe340b +11: nop 0xb7fe340c +12: nop 0xb7fe340d +13: nop 0xb7fe340e +14: jmp0xb7fe3403 __kernel_vsyscall+3 = 0xb7fe3410 +16: pop%ebp 0xb7fe3411 +17: pop%edx 0xb7fe3412 +18: pop%ecx 0xb7fe3413 +19: ret End of assembler dump. (gdb) p $pc $1 = (void (*)()) 0xb7fe3410 __kernel_vsyscall+16 (gdb) p $pc=0xb7fe3413 $2 = (void (*)()) 0xb7fe3413 __kernel_vsyscall+19 (gdb) si infrun: clear_proceed_status_thread (process 4542) infrun: proceed (addr=0x, signal=144, step=1) infrun: resume (step=1, signal=0), trap_expected=0 infrun: wait_for_inferior (treat_exec_as_sigtrap=0) infrun: target_wait (-1, status) = infrun: 4542 [process 4542], infrun: status-kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0xb7fe3412 infrun: stepi/nexti infrun: stop_stepping 0xb7fe3412 in __kernel_vsyscall () Thanks, Hui On Nov 2, 7:27 pm, Alexandre Rusev aru...@ru.mvista.com wrote: teawater wrote: This signal ctrl-c will not really send to inferior. But the result is interrupted system call which is restarted then by kernel. And is user changes program counter in GDB at this point, then it takes place before the modification of PC is done by kernel. The result is that execution jumps neither to the point the user said in GDB nor to the point the kernel wishes it be due to restart the syscall. Is it incorrect behavior of GDB or incorrect behavior of kernel or something else??? (gdb) help info handle On Oct 31, 12:10 am, Alexandre Rusev aru...@ru.mvista.com wrote: Hi. When the program at ht end of message debugged under GDB is stopped with Ctrl+C it's usually found in interrupted system call. (The same result is observed for x86 and PPC with kernels 2.6.18 and 2.6.28) (gdb) where #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb7f36ad0 in nanosleep () from /lib/libc.so.6 #2 0xb7f3690e in sleep () from /lib/libc.so.6 #3 0x08048600 in qqq () at testBT2.c:45 #4 0x080487a5 in eee () at testBT2.c:73 #5 0x0804846a in main () at testBT2.c:17 The PC is pointing at the next instruction, accordingly to GDB. But the kernel tries to restart syscall by means of
Re: Problem of GDB interaction with interrupted system calls
teawater wrote: I think this is a hehavior of kernel. I think change pc always a danger thing. :) Yes, extremely dangeorous! ;) But GDB supports feature such as call func_name, when using it the Joe user does not even cares the PC, he just thinks that he makes call to some function... Moreover the intent of changing stack by kernel is to make system call to restart. The kernel (in theory) could choose to not return to userland at this point (because of no signal handlers are set by the process) and restart syscall internally. If it where so, all the process could have been transparent for GDB. And this usecase is enounted quite often by users:( Because the nature of the problem is quite clear, it could be (once in theory) worked around both in kernel and in GDB. Because the GDB does a lot of tricks and serves to thecnical puroses may be it it the best place to implement workaround there? Yet from point of view of kernel that's the place where either nobody (even GDB) is supposed to intervien the kernel internal housekeeping, at least till the next machine instruction is executed. So the kernel could either: [1] not enable the GDB/ptrace to stop process and change user registers at that point [2] remember the state of essential registers (PC, may be others likes FP) and revert all changes before executing the next instruction [3] remember the state of essential registers (PC, may be others likes FP) and if the process was stopped and somebody (GDB/ptrace) changed PC before execution of the next instruction then kernel can avoid it's own changes of PC Anyway the problem exists and I'm trying at least to find out where needs to be fixed infrun: clear_proceed_status_thread (process 4542) infrun: proceed (addr=0x, signal=144, step=0) infrun: resume (step=0, signal=0), trap_expected=0 infrun: wait_for_inferior (treat_exec_as_sigtrap=0) infrun: target_wait (-1, status) = infrun: 4542 [process 4542], infrun: status-kind = stopped, signal = SIGINT infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0xb7fe3410 infrun: random signal 2 Program received signal SIGINT, Interrupt. infrun: stop_stepping 0xb7fe3410 in __kernel_vsyscall () (gdb) disas Dump of assembler code for function __kernel_vsyscall: 0xb7fe3400 +0: push %ecx 0xb7fe3401 +1: push %edx 0xb7fe3402 +2: push %ebp 0xb7fe3403 +3: mov%esp,%ebp 0xb7fe3405 +5: sysenter 0xb7fe3407 +7: nop 0xb7fe3408 +8: nop 0xb7fe3409 +9: nop 0xb7fe340a +10: nop 0xb7fe340b +11: nop 0xb7fe340c +12: nop 0xb7fe340d +13: nop 0xb7fe340e +14: jmp0xb7fe3403 __kernel_vsyscall+3 = 0xb7fe3410 +16: pop%ebp 0xb7fe3411 +17: pop%edx 0xb7fe3412 +18: pop%ecx 0xb7fe3413 +19: ret End of assembler dump. (gdb) p $pc $1 = (void (*)()) 0xb7fe3410 __kernel_vsyscall+16 (gdb) p $pc=0xb7fe3413 $2 = (void (*)()) 0xb7fe3413 __kernel_vsyscall+19 (gdb) si infrun: clear_proceed_status_thread (process 4542) infrun: proceed (addr=0x, signal=144, step=1) infrun: resume (step=1, signal=0), trap_expected=0 infrun: wait_for_inferior (treat_exec_as_sigtrap=0) infrun: target_wait (-1, status) = infrun: 4542 [process 4542], infrun: status-kind = stopped, signal = SIGTRAP infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0xb7fe3412 infrun: stepi/nexti infrun: stop_stepping 0xb7fe3412 in __kernel_vsyscall () Thanks, Hui On Nov 2, 7:27 pm, Alexandre Rusev aru...@ru.mvista.com wrote: teawater wrote: This signal ctrl-c will not really send to inferior. But the result is interrupted system call which is restarted then by kernel. And is user changes program counter in GDB at this point, then it takes place before the modification of PC is done by kernel. The result is that execution jumps neither to the point the user said in GDB nor to the point the kernel wishes it be due to restart the syscall. Is it incorrect behavior of GDB or incorrect behavior of kernel or something else??? (gdb) help info handle On Oct 31, 12:10 am, Alexandre Rusev aru...@ru.mvista.com wrote: Hi. When the program at ht end of message debugged under GDB is stopped with Ctrl+C it's usually found in interrupted system call. (The same result is observed for x86 and PPC with kernels 2.6.18 and 2.6.28) (gdb) where #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb7f36ad0 in nanosleep () from /lib/libc.so.6 #2 0xb7f3690e in sleep () from /lib/libc.so.6 #3 0x08048600 in qqq () at testBT2.c:45 #4 0x080487a5 in eee () at testBT2.c:73 #5 0x0804846a in main () at testBT2.c:17 The PC is pointing at the next instruction, accordingly to GDB. But the kernel tries to restart syscall by means of changing PC to PC-4 (in case of PowerPC and to some other value for x86) and it does it's change to PC after the
Re: Problem of GDB interaction with interrupted system calls
I think this is a hehavior of kernel. I think change pc always a
danger thing. :)
infrun: clear_proceed_status_thread (process 4542)
infrun: proceed (addr=0x, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun: 4542 [process 4542],
infrun: status-kind = stopped, signal = SIGINT
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xb7fe3410
infrun: random signal 2
Program received signal SIGINT, Interrupt.
infrun: stop_stepping
0xb7fe3410 in __kernel_vsyscall ()
(gdb) disas
Dump of assembler code for function __kernel_vsyscall:
0xb7fe3400 +0: push %ecx
0xb7fe3401 +1: push %edx
0xb7fe3402 +2: push %ebp
0xb7fe3403 +3: mov%esp,%ebp
0xb7fe3405 +5: sysenter
0xb7fe3407 +7: nop
0xb7fe3408 +8: nop
0xb7fe3409 +9: nop
0xb7fe340a +10:nop
0xb7fe340b +11:nop
0xb7fe340c +12:nop
0xb7fe340d +13:nop
0xb7fe340e +14:jmp0xb7fe3403 __kernel_vsyscall+3
= 0xb7fe3410 +16:pop%ebp
0xb7fe3411 +17:pop%edx
0xb7fe3412 +18:pop%ecx
0xb7fe3413 +19:ret
End of assembler dump.
(gdb) p $pc
$1 = (void (*)()) 0xb7fe3410 __kernel_vsyscall+16
(gdb) p $pc=0xb7fe3413
$2 = (void (*)()) 0xb7fe3413 __kernel_vsyscall+19
(gdb) si
infrun: clear_proceed_status_thread (process 4542)
infrun: proceed (addr=0x, signal=144, step=1)
infrun: resume (step=1, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun: 4542 [process 4542],
infrun: status-kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0xb7fe3412
infrun: stepi/nexti
infrun: stop_stepping
0xb7fe3412 in __kernel_vsyscall ()
Thanks,
Hui
On Nov 2, 7:27 pm, Alexandre Rusev aru...@ru.mvista.com wrote:
teawater wrote:
This signal ctrl-c will not really send to inferior.
But the result is interrupted system call which is restarted then by kernel.
And is user changes program counter in GDB at this point,
then it takes place before the modification of PC is done by kernel.
The result is that execution jumps neither to the point the user said in
GDB nor
to the point the kernel wishes it be due to restart the syscall.
Is it incorrect behavior of GDB or incorrect behavior of kernel or
something else???
(gdb) help info handle
On Oct 31, 12:10 am, Alexandre Rusev aru...@ru.mvista.com wrote:
Hi.
When the program at ht end of message debugged under GDB is stopped with
Ctrl+C
it's usually found in interrupted system call. (The same result is
observed for x86 and PPC with kernels 2.6.18 and 2.6.28)
(gdb) where
#0 0xb7fe2424 in __kernel_vsyscall ()
#1 0xb7f36ad0 in nanosleep () from /lib/libc.so.6
#2 0xb7f3690e in sleep () from /lib/libc.so.6
#3 0x08048600 in qqq () at testBT2.c:45
#4 0x080487a5 in eee () at testBT2.c:73
#5 0x0804846a in main () at testBT2.c:17
The PC is pointing at the next instruction, accordingly to GDB.
But the kernel tries to restart syscall by means of changing PC to PC-4
(in case of PowerPC and to some other value for x86)
and it does it's change to PC after the user continues execution of
program in GDB with cont or si command.
The issue is that if user changed PC at this point or uses call
func_name GDB command, the both changes to PC
are added (as kernel uses PC relative change i.e. PC - 4), and the
program continues execution at absolutely wrong place.
The issue may be gracefully observed if breakpoint is set just before
func_name and then PC is changed to the func_name address.
In such case the breakpoint is hit while it must not be.
#include stdio.h
#include stdlib.h
void qqq();
void www();
void eee();
void * xrealloc(void*, int);
int main(void)
{
eee();
return EXIT_SUCCESS;
}
void qqq() {
void *a[256];
size_t i, n;
for (i = 0; i 256; i++)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i] = malloc(n);
}
for (i = 256; i 0; i--)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i - 1] = xrealloc(a[i - 1], n);
}
sleep(1);
for (i = 0; i 256; i += 2)
free(a[i]);
for (i = 256; i 0; i -= 2)
free(a[i - 1]);
sleep(1);
}
void www() {
void *a[256];
size_t i, n;
for (i = 0; i 256; i++)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i] = malloc(n);
}
for (i = 256; i 0; i--)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i - 1] = realloc(a[i - 1], n);
}
sleep(1);
for (i = 0; i 256; i += 2)
free(a[i]);
for (i = 256; i 0; i -= 2)
Re: Problem of GDB interaction with interrupted system calls
teawater wrote:
This signal ctrl-c will not really send to inferior.
But the result is interrupted system call which is restarted then by kernel.
And is user changes program counter in GDB at this point,
then it takes place before the modification of PC is done by kernel.
The result is that execution jumps neither to the point the user said in
GDB nor
to the point the kernel wishes it be due to restart the syscall.
Is it incorrect behavior of GDB or incorrect behavior of kernel or
something else???
(gdb) help info handle
On Oct 31, 12:10 am, Alexandre Rusev aru...@ru.mvista.com wrote:
Hi.
When the program at ht end of message debugged under GDB is stopped with
Ctrl+C
it's usually found in interrupted system call. (The same result is
observed for x86 and PPC with kernels 2.6.18 and 2.6.28)
(gdb) where
#0 0xb7fe2424 in __kernel_vsyscall ()
#1 0xb7f36ad0 in nanosleep () from /lib/libc.so.6
#2 0xb7f3690e in sleep () from /lib/libc.so.6
#3 0x08048600 in qqq () at testBT2.c:45
#4 0x080487a5 in eee () at testBT2.c:73
#5 0x0804846a in main () at testBT2.c:17
The PC is pointing at the next instruction, accordingly to GDB.
But the kernel tries to restart syscall by means of changing PC to PC-4
(in case of PowerPC and to some other value for x86)
and it does it's change to PC after the user continues execution of
program in GDB with cont or si command.
The issue is that if user changed PC at this point or uses call
func_name GDB command, the both changes to PC
are added (as kernel uses PC relative change i.e. PC - 4), and the
program continues execution at absolutely wrong place.
The issue may be gracefully observed if breakpoint is set just before
func_name and then PC is changed to the func_name address.
In such case the breakpoint is hit while it must not be.
#include stdio.h
#include stdlib.h
void qqq();
void www();
void eee();
void * xrealloc(void*, int);
int main(void)
{
eee();
return EXIT_SUCCESS;
}
void qqq() {
void *a[256];
size_t i, n;
for (i = 0; i 256; i++)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i] = malloc(n);
}
for (i = 256; i 0; i--)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i - 1] = xrealloc(a[i - 1], n);
}
sleep(1);
for (i = 0; i 256; i += 2)
free(a[i]);
for (i = 256; i 0; i -= 2)
free(a[i - 1]);
sleep(1);
}
void www() {
void *a[256];
size_t i, n;
for (i = 0; i 256; i++)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i] = malloc(n);
}
for (i = 256; i 0; i--)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i - 1] = realloc(a[i - 1], n);
}
sleep(1);
for (i = 0; i 256; i += 2)
free(a[i]);
for (i = 256; i 0; i -= 2)
free(a[i - 1]);
sleep(1);
}
void eee() {
while (1) {
qqq();
www();
}
}
void * xrealloc(void* addr, int n) {
return realloc(addr, n);
}
___
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
___
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: Problem of GDB interaction with interrupted system calls
This signal ctrl-c will not really send to inferior.
(gdb) help info handle
On Oct 31, 12:10 am, Alexandre Rusev aru...@ru.mvista.com wrote:
Hi.
When the program at ht end of message debugged under GDB is stopped with
Ctrl+C
it's usually found in interrupted system call. (The same result is
observed for x86 and PPC with kernels 2.6.18 and 2.6.28)
(gdb) where
#0 0xb7fe2424 in __kernel_vsyscall ()
#1 0xb7f36ad0 in nanosleep () from /lib/libc.so.6
#2 0xb7f3690e in sleep () from /lib/libc.so.6
#3 0x08048600 in qqq () at testBT2.c:45
#4 0x080487a5 in eee () at testBT2.c:73
#5 0x0804846a in main () at testBT2.c:17
The PC is pointing at the next instruction, accordingly to GDB.
But the kernel tries to restart syscall by means of changing PC to PC-4
(in case of PowerPC and to some other value for x86)
and it does it's change to PC after the user continues execution of
program in GDB with cont or si command.
The issue is that if user changed PC at this point or uses call
func_name GDB command, the both changes to PC
are added (as kernel uses PC relative change i.e. PC - 4), and the
program continues execution at absolutely wrong place.
The issue may be gracefully observed if breakpoint is set just before
func_name and then PC is changed to the func_name address.
In such case the breakpoint is hit while it must not be.
#include stdio.h
#include stdlib.h
void qqq();
void www();
void eee();
void * xrealloc(void*, int);
int main(void)
{
eee();
return EXIT_SUCCESS;
}
void qqq() {
void *a[256];
size_t i, n;
for (i = 0; i 256; i++)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i] = malloc(n);
}
for (i = 256; i 0; i--)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i - 1] = xrealloc(a[i - 1], n);
}
sleep(1);
for (i = 0; i 256; i += 2)
free(a[i]);
for (i = 256; i 0; i -= 2)
free(a[i - 1]);
sleep(1);
}
void www() {
void *a[256];
size_t i, n;
for (i = 0; i 256; i++)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i] = malloc(n);
}
for (i = 256; i 0; i--)
{
n = (size_t) ((rand() * 256.0) / (RAND_MAX + 1.0)) + 1;
a[i - 1] = realloc(a[i - 1], n);
}
sleep(1);
for (i = 0; i 256; i += 2)
free(a[i]);
for (i = 256; i 0; i -= 2)
free(a[i - 1]);
sleep(1);
}
void eee() {
while (1) {
qqq();
www();
}
}
void * xrealloc(void* addr, int n) {
return realloc(addr, n);
}
___
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: Problem compiling gdb/symtab.c in GDB 6.7.1 using GCC 4.3.0 on Solaris 10 (already fixed in GDB 6.8 code)
Dear Bug-GDB Team,
This got entered into GCC's Bugzilla as Bug 35534. It has been closed, but
you can follow events there.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35534
Having downloaded a CVS snapshot of GDB 6.8 code, there is a coded fix for
the problem in the (static) function find_line_common(), which indeed had a
pair of return statements wherein 'exact' was not assigned a value. Close
human inspection of the code can see that when exact is not set, best_index
is negative so exact is not read. However, it would be pushing the compiler
to the limits to spot that.
Since the fix is already coded in the dev snapshot, you don't need to open a
bug for this - or you can close the bug created for it if one was already
created. But be aware that people will run into this problem if they
compile GDB 6.7.1 with GCC 4.3.0.
Sorry for any trouble I have caused.
On Mon, Mar 10, 2008 at 8:24 PM, Jonathan Leffler
[EMAIL PROTECTED] wrote:
I'm not clear whether this is a problem in GCC or in GDB, so I'm asking
both teams.
Compiling gdb 6.7.1 on Solaris 10 using the newly installed GCC 4.3.0, I
got a compilation error (because of the -Werror option) as shown:
gcc -c -g -O2-I. -I.././gdb -I.././gdb/config
-DLOCALEDIR=\/usr/gdb/v6.7.1/share/locale\ -DHAVE_CONFIG_H
-I.././gdb/../include/opcode -I.././gdb/../readline/.. -I../bfd
-I.././gdb/../bfd -I.././gdb/../include -I./../intl -DMI_OUT=1 -DTUI=1
-Wall -Wdeclaration-after-statement -Wpointer-arith -Wformat-nonliteral
-Wno-pointer-sign -Wno-unused -Wno-switch -Wno-char-subscripts -Werror
symtab.c
cc1: warnings being treated as errors
symtab.c: In function 'find_line_symtab':
symtab.c:2252: error: 'exact' may be used uninitialized in this function
make: *** [symtab.o] Error 1
The fragment in question was 'worked around' by adding the '= 0' to the
declaration of 'exact' at:
struct symtab *
find_line_symtab (struct symtab *symtab, int line, int *index, int
*exact_match)
{
int exact = 0;
/* BEST_INDEX and BEST_LINETABLE identify the smallest linenumber LINE
so far seen. */
int best_index;
struct linetable *best_linetable;
struct symtab *best_symtab;
/* First try looking it up in the given symtab. */
best_linetable = LINETABLE (symtab);
best_symtab = symtab;
best_index = find_line_common (best_linetable, line, exact);
if (best_index 0 || !exact)
{
It is not clear to me that GCC is entitled to complain. However, given
that it does, the workaround at least allows the compilation to proceed.
[...]
--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2008.0229 - http://dbi.perl.org
Blessed are we who can laugh at ourselves, for we shall never cease to be
amused.
___
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb
a problem with gdb?
Hi, When I was debuging a program withe gdb, it reported a problem as the following: warning: Unexpected waitpid result 03057f when waiting for vfork-done ../../gdb-6.3/gdb/linux-nat.c:520: internal-error: unknown ptrace event 5 A problem internal to GDB has been detected, further debugging may prove unreliable. ---Type return to continue, or q return to quit--- Quit this debugging session? (y or n) y ../../gdb-6.3/gdb/linux-nat.c:520: internal-error: unknown ptrace event 5 A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Abort I've no idea on itIs there anything wrong with my program or with GDB? Could anyone give me a hint? Thanks a lot in advance. my gdb version: GNU gdb Red Hat Linux (6.3.0.0-0.30.1rh) Erming ___ Bug-gdb mailing list Bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb
Re: a problem about gdb (can you help me)
Please download and try GDB 5.2.1 (http://www.gnu.org/software/gdb/ ). If the problem is still present then please report it using http://www.gnu.org/software/gdb/bugs/ . Andrew ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
a problem about gdb (can you help me)
Hi,I'm not sure whether this is a bug of gdb 5.0.I
made a very simple multi-threaded program in RedHat 7.1 andtried to debug it
with gdb 5.0 that is distributed on May 2000.When I run the program in gdb
5.0,it shows "Program exits with code 01" in the middle of execution of the
program.
Following is my multi-threaded program.It
createspthreas.
test.c
#include pthread.hvoid* runProc();int
main(){pthread_t threadID;
pthread_create(threadID,NULL,runProc,NULL);
printf("main-threadID:
%d\n",threadID);}void*
runProc(){pthread_t threadID;
pthread_create(threadID,NULL,runProc,NULL);
printf("runProc-threadID: %d\n",threadID);
return NULL;}
compile : gcc -o test test.c -lpthreadFollowing is the
result of debugging my program with gdb 5.0:
gdb testGNU gdb 5.0rh-5 Red Hat Linux 7.1Copyright
2000 Free Software Foundation, Inc.GDB is free software, covered by the GNU
General Public License, and you arewelcome to change it and/or distribute
copies of it under certainconditions.Type "show copying" to see the
conditions.There is absolutely no warranty for GDB. Type "show
warranty" for details.This GDB was configured as "i686-pc-linux"...(gdb)
runStarting program: /root/test[New Thread 1024 (LWP 3122)][New
Thread 2049 (LWP 3123)]Delayed SIGSTOP caught for LWP 3123.
[New Thread 1026 (LWP 3124)]
Delayed SIGSTOP caught for LWP 3124.
ReceivedReal-timesignal 0 in LWP 3122 while
waiting for SIGSTOP.
[New Thread 2051 (LWP 3125)]
Using pending wait status for LWP 3122.
main-threadID; 1026
Delayed SIGSTOP caught for LWP 3125.
LWP 3123 exited.
LWP 3125 exited.
LWP 3124 exited.
Program exited with code 01.
(gdb) quit
2002/8/1anny
** PID[31946],THR[1026]: digit=00[New
Thread 2051 (LWP 31947)]00 ** PID[31947],THR[2051]:
digit=101[New Thread 3076 (LWP 31948)]011 **
PID[31948],THR[3076]: digit=212Program exited normally.(gdb)
1(gdb) info threadsNo stack.(gdb) btNo stack.(gdb)
quit[htlim@esto
testgdb]$==ENDOnly
three pthreads are created and my program dies without creating fourthand
fifth pthreads.But debugging my program with a gdb that comes with
RedHat 7.1 works nicely.Following is the result of debugging my program with
gdb in RedHat
7.1.==BEGIN==[htlim@esto
testgdb]$ gdb mthrtest1GNU gdb 5.0rh-5 Red Hat Linux 7.1Copyright 2001
Free Software Foundation, Inc.GDB is free software, covered by the GNU
General Public License, and you arewelcome to change it and/or distribute
copies of it under certainconditions.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"...(gdb) runStarting program:
/home/htlim/testgdb/mthrtest1[New Thread 1024 (LWP 31951)] **
main thread:PID[31951],THR[1024][New Thread 2049 (LWP 31952)]Delayed
SIGSTOP caught for LWP 31952.[New Thread 1026 (LWP 31953)]Delayed
SIGSTOP caught for LWP 31953. ** PID[31953],THR[1026]:
digit=0[New Thread 2051 (LWP 31954)]Delayed SIGSTOP caught for LWP
31954.0 ** PID[31954],THR[2051]: digit=1[New Thread 3076 (LWP
31955)]Delayed SIGSTOP caught for LWP 31955.10 **
PID[31955],THR[3076]: digit=2[New Thread 4101 (LWP 31956)]Delayed
SIGSTOP caught for LWP 31956.210 ** PID[31956],THR[4101]:
digit=3[New Thread 5126 (LWP 31957)]Delayed SIGSTOP caught for LWP
31957.3210 ** PID[31957],THR[5126]: digit=401234LWP 31953
exited. ** THR[1026] terminated1234LWP 31954 exited. **
THR[2051] terminated234LWP 31955 exited. ** THR[3076]
terminated34LWP 31956 exited. ** THR[4101] terminated4LWP
31957 exited. ** THR[5126] terminated Test program
terminates LWP 31952 exited.Program exited normally.(gdb)
quit[htlim@esto
testgdb]$==END
Re: Problem with gdb and C++ namespaes
In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... I use gdb to debug Test by setting a breakpoint a line 24 and running the code. When I try to print test_ns1::Test::i, I get a No symbol test_ns1 in current context. error. I also get a similar error when trying to print test_ns2::Test::i. I can print Test::i, which seems to show the value of test_ns1::Test::i. Here's the output from gdb: Try single-quoting 'test_ns2::Test::i'. Does that work? -- Jay Levitt| This is not the start of World War III Chief Mail Systems Architect | No political ploys America Online, Inc. | I think both your constitutions are [EMAIL PROTECTED] | terrific, so now you know - be good boys. ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: Problem with gdb and C++ namespaes
Can anyone help with this? Thanks, Geoff Alexander, Ph.D. 919/254-5216 T/L 444-5216 [EMAIL PROTECTED] CMVC95 WebDAV Development IBM Corporation RTP, NC ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
Re: problem compiling gdb-5.0
Roberto Chiarle wrote: gcc -I. -I../common -I./../common -o gentmap gcc: No input files *** Error code 1 Your version of "make" doesn't understand the $ macro. Fix gdb-5.0/sim/ppc/Makefile.in to say $(CC) -c $(STD_CFLAGS) -DHAVE_CONFIG_H ../common/callback.c instead of $(CC) -c $(STD_CFLAGS) -DHAVE_CONFIG_H $ and $(CC_FOR_BUILD) $(BUILD_FLAGS) -I. -I../common -I$(srcdir)/../common -o gentmap ../common/gentmap.c $(BUILD_LIBS) instead of $(CC_FOR_BUILD) $(BUILD_FLAGS) -I. -I../common -I$(srcdir)/../common -o gentmap $ $(BUILD_LIBS) -- Christopher S. Kush ___ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
