Re: Resolved: Problem with gdb/mi under hp-ux 11.11, gdb 6.7.1: our version of gcc was broken.

Thomas Mittelstaedt
2008-01-08T16:46:52Z

Just to let you know: Looks like our build of gcc 4.1 was simply broken
somehow.
Installed gcc 4.2.1 which I downloaded from hp's dspp website, and
ccdebug works okay so far.

thomas

Thomas Mittelstaedt schrieb:
> Hallo,
>
> Here is a stack trace
>
> I also filed a bug report, it has identification mi/2374.
>
> #7 0x64e44 in unpack_long (type=0x7b041f20, valaddr=0x7b0416b8
> "\341yd\225{\003\006\230z\271\2468") at
> /localbuild/source/gdb-6.7.1/gdb/value.c:1097
> (gdb) do
> #6 0xc0161bcc in _U_Qfcnvfxt_quad_to_dbl+0xb4 () from /usr/lib/libc.2
> (gdb)
> #5 0xc015fd68 in _U_force_trap+0 () from /usr/lib/libc.2
> (gdb)
> #4 <signal handler called>
> (gdb) do
> #3 0x8b9bc in handle_sigfpe (sig=8) at
> /localbuild/source/gdb-6.7.1/gdb/event-top.c:1096
> (gdb) bt
> #0 0xc02012e0 in _sigvector+0x10 () from /usr/lib/libc.2
> #1 0xc0207d3c in signalvector+0xac () from /usr/lib/libc.2
> #2 0xc0207c48 in signal+0xa0 () from /usr/lib/libc.2
> #3 0x8b9bc in handle_sigfpe (sig=8) at
> /localbuild/source/gdb-6.7.1/gdb/event-top.c:1096
> #4 <signal handler called>
> #5 0xc015fd68 in _U_force_trap+0 () from /usr/lib/libc.2
> #6 0xc0161bcc in _U_Qfcnvfxt_quad_to_dbl+0xb4 () from /usr/lib/libc.2
> #7 0x64e44 in unpack_long (type=0x7b041f20, valaddr=0x7b0416b8
> "\341yd\225{\003\006\230z\271\2468") at
> /localbuild/source/gdb-6.7.1/gdb/value.c:1097
> #8 0x76634 in print_scalar_formatted (valaddr=0x7b0416b8,
> type=0x4003bca8, format=120, size=0, stream=0x400739c0) at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/printcmd.c:354
> #9 0x18d37c in c_val_print (type=0x40084c20, valaddr=0x240800 "e",
> embedded_offset=1073762000, address=0, stream=0x400739c0, format=120,
> deref_ref=1, recurse=0, pretty=Val_no_prettyprint) at
> /localbuild/source/gdb-6.7.1/gdb/c-valprint.c:469
> #10 0x7338c in val_print (type=0x7b041928, valaddr=0x7b041838 "",
> embedded_offset=42, address=2235956, stream=0x400739c0, format=120,
> deref_ref=1, recurse=0, pretty=Val_pretty_default) at
> /localbuild/source/gdb-6.7.1/gdb/valprint.c:230
> #11 0x161b80 in get_register (regnum=2063865528, format=2063865528) at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/mi/mi-main.c:569
> #12 0x161f14 in mi_cmd_data_list_register_values (command=0x7b027b78 "",
> argv=0x2, argc=121) at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/mi/mi-main.c:484
> #13 0x16066c in captured_mi_execute_command (uiout=0x0, data=0x7b026f38)
> at /localbuild/source/gdb-6.7.1/gdb/.././gdb/mi/mi-main.c:1319
> #14 0x3dfac in catch_exception (uiout=0x40038aa8, func=0x7b030690,
> func_args=0x7b026f38, mask=1073861092) at
> /localbuild/source/gdb-6.7.1/gdb/exceptions.c:467
> #15 0x15ff9c in mi_execute_command (cmd=0x7b030958 "",
> from_tty=2063795856) at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/mi/mi-main.c:1243
> #16 0xddd2c in mi_execute_command_wrapper (cmd=0x7b026f38 "") at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/mi/mi-interp.c:283
> #17 0x8bff8 in gdb_readline2 (client_data=0x40038aa8) at
> /localbuild/source/gdb-6.7.1/gdb/event-top.c:885
> #18 0x8c190 in stdin_event_handler (error=2063796560,
> client_data=0x40073cb4) at /localbuild/source/gdb-6.7.1/gdb/event-top.c:431
> #19 0x8afb4 in handle_file_event (event_file_desc=0) at
> /localbuild/source/gdb-6.7.1/gdb/event-loop.c:728
> #20 0x8a0d8 in process_event () at
> /localbuild/source/gdb-6.7.1/gdb/event-loop.c:341
> #21 0x8abc8 in gdb_do_one_event (data=0x4006ab98) at
> /localbuild/source/gdb-6.7.1/gdb/event-loop.c:378
> #22 0x3dda8 in catch_errors (func=0x7b032e90, func_args=0x0,
> errstring=0x0, mask=1074170312) at
> /localbuild/source/gdb-6.7.1/gdb/exceptions.c:513
> #23 0x8aa3c in start_event_loop () at
> /localbuild/source/gdb-6.7.1/gdb/event-loop.c:404
> #24 0xddff4 in mi_command_loop (mi_version=2063806096) at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/mi/mi-interp.c:351
> #25 0x3e3d8 in current_interp_command_loop () at
> /localbuild/source/gdb-6.7.1/gdb/interps.c:273
> #26 0x2a7dc in captured_command_loop (data=0x400689d0) at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/main.c:99
> #27 0x3dda8 in catch_errors (func=0, func_args=0x0, errstring=0x0,
> mask=0) at /localbuild/source/gdb-6.7.1/gdb/exceptions.c:513
> #28 0x2a0b0 in captured_main (data=0x40038aa8) at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/main.c:870
> #29 0x3dda8 in catch_errors (func=0, func_args=0x0, errstring=0x1f1998
> "console", mask=0) at /localbuild/source/gdb-6.7.1/gdb/exceptions.c:513
> #30 0x296f0 in gdb_main (args=0x0) at
> /localbuild/source/gdb-6.7.1/gdb/.././gdb/main.c:879
> #31 0x296b0 in main (argc=0, argv=0x0) at
> /localbuild/source/gdb-6.7.1/gdb/gdb.c:33
> (gdb) f 7
> #7 0x64e44 in unpack_long (type=0x7b041f20, valaddr=0x7b0416b8
> "\341yd\225{\003\006\230z\271\2468") at
> /localbuild/source/gdb-6.7.1/gdb/value.c:1097
> (gdb) p valaddr
> $15 = (unsigned char *) 0x7b0416b8 "\341yd\225{\003\006\230z\271\2468"
> (gdb) do
>
>
>
> Thomas Mittelstaedt schrieb:
>
>> Hallo,
>>
>> Some more investigation shows that the forked gdb runs at about 90+ %
>> CPU and the truss
>> output shows that floating point exceptions occur.
>>
>> sigvec(SIGFPE, 0x7b042560,
>> 0x7b042570) = 0
>> Received signal 8, SIGFPE, in user mode, [caught], partial siginfo
>> Siginfo: si_code: I_EXCEP, faulting address: 0xc015fd6b, si_errno: 0
>> PC: 0xc015fd6b, instruction: 0x27c11200
>> sigvec(SIGFPE, 0x7b042560,
>> 0x7b042570) = 0
>> Received signal 8, SIGFPE, in user mode, [caught], partial siginfo
>> Siginfo: si_code: I_EXCEP, faulting address: 0xc015fd6b, si_errno: 0
>> PC: 0xc015fd6b, instruction: 0x27c11200
>> sigvec(SIGFPE, 0x7b042560,
>> 0x7b042570) = 0
>> Received signal 8, SIGFPE, in user mode, [caught], partial siginfo
>> Siginfo: si_code: I_EXCEP, faulting address: 0xc015fd6b, si_errno: 0
>> PC: 0xc015fd6b, instruction: 0x27c11200
>>
>>
>> Thomas Mittelstaedt schrieb:
>>
>>
>>> Hallo,
>>>
>>> I am trying to get ccdebug <http://ccdebug.sourceforge.net/>, a Qt-based
>>> gdb frontend to work on hp-ux. It works without problems on linux. On
>>> hp-ux, though, and also on aix,
>>> I am having trouble when I hit the key to show the register values. The
>>> funny thing is, sometimes it works, but mostly it does not, i.e. there is no
>>> response from the forked gdb, because otherwise I would see it in the log.
>>> The following command is sent to gdb, but no response arrives.
>>>
>>> ^[[46mSent: -data-list-register-values x ^[[0m
>>>
>>> What can this be and how can I test this?
>>>
>>> Also, when I try to debug ccdebug with gdb directly, I get a ttrace:
>>> Protocol error.
>>> Attaching to the running process also does not work.
>>>
>>> tmstaedt@buildhp3$ gdb ../ccdebug
>>> GNU gdb 6.7.1
>>> Copyright (C) 2007 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>>> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "hppa2.0w-hp-hpux11.11"...
>>> (gdb) r
>>> Starting program:
>>> /localbuild/source/V9_UNICODE_RESTRUCTURE/3rdparty/ccdebug/ccdebug
>>> warning: The shared libraries were not privately mapped; setting a
>>> breakpoint in a shared library will not work until you rerun the program.
>>>
>>> [New process 3561, lwp 1296829]
>>> Using /opt/gcc-4.1/32/bin/gdb
>>> Detaching after fork from child process 3567.
>>> [Switching to process 3561, lwp 1296829]
>>> 0x7affe5d4 in _fork_sys () from /usr/lib/libc.2
>>> ttrace: Protocol error.
>>>
>>>
>>>
>>> gcc -v
>>> Reading specs from
>>> /opt/gcc/gcc-4.1/32/lib/gcc/hppa2.0w-hp-hpux11.11/4.1.1/specs
>>> Target: hppa2.0w-hp-hpux11.11
>>> Configured with: ../gcc-4.1.1/configure --prefix=/opt/gcc-4.1-32
>>> --enable-version-specific-runtime-libs --enable-static --enable-shared
>>> --with-gnu-as --with-as=/opt/gcc-4.1-32/bin/as --enable-threads=posix
>>> --disable-nls --enable-languages=c,c++
>>> Thread model: posix
>>> gcc version 4.1.1
>>>
>>>
>>> Thanks in advance for help,
>>> thomas
>>>
>>>
>>>
>>>