public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Thomas Mittelstaedt <T.Mittelstaedt@cadenas.de>
To: gdb@sourceware.org
Subject: Re: Resolved: Problem with gdb/mi under hp-ux 11.11, gdb 6.7.1: our  version of gcc was broken.
Date: Tue, 08 Jan 2008 16:46:00 -0000	[thread overview]
Message-ID: <4783AA58.4080308@cadenas.de> (raw)
In-Reply-To: <4750072B.20103@cadenas.de>

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

      reply	other threads:[~2008-01-08 16:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-28 15:14 Problem with gdb/mi under hp-ux 11.11, aix 5.2, gdb 6.7.1 Thomas Mittelstaedt
2007-11-28 15:31 ` Thomas Mittelstaedt
2007-11-30 12:45   ` Problem with gdb/mi under hp-ux 11.11, " Thomas Mittelstaedt
2008-01-08 16:46     ` Thomas Mittelstaedt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4783AA58.4080308@cadenas.de \
    --to=t.mittelstaedt@cadenas.de \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).