From: John Fine <johnsfine@verizon.net>
To: Keith Seitz <keiths@redhat.com>
Cc: insight@sourceware.org
Subject: Re: Can't debug x86_64 C++ programs.
Date: Thu, 18 Sep 2008 23:25:00 -0000 [thread overview]
Message-ID: <48D15FD3.8020802@verizon.net> (raw)
In-Reply-To: <48D1342F.7040703@redhat.com>
Keith Seitz wrote:
>
> That sounds like a plausible explanation. You might try to see if
> numregs is changing or if the register number is greater than the
> amount that has been allocated.
>
> It shouldn't, but who knows. There has been a fair amount of churn in
> this area in gdb over the last year.
>
This is a situation in which I really could use a decent 64-bit debugger
(to find the bug in gdb/Insight). But I don't know how to use gdb
beyond the simplest operations. I wouldn't even know how to try to used
gdb to debug itself.
So I wasted lots of time trying to use
fprintf_unfiltered (gdb_stdlog,
Then I realized most of those were just trying to pop up in a window
when Insight crashed, so I would never get to see them.
So I tried ordinary printf and verified what I expected. But I still
don't know enough about gdb/Insight internals to know exactly where the
bug is. I'm not even sure yet whether it is gdb or insight (though I'm
looking at code that is apparently gdb.
I put printf's in
architecture_changed_event
deprecated_current_gdbarch_select_hack
setup_architecture_data
and
gdb_regformat
The output I get from my printf's is
deprecated_current_gdbarch_select_hack() current_gdbarch=0xa89450
architecture_changed_event
setup_architecture_data() current_gdbarch=0xa89450 numregs=50
old_regs=0xc98ab0 regformat=0xc98de0 regtype=0xc98eb0
deprecated_current_gdbarch_select_hack() current_gdbarch=0xc9de00
architecture_changed_event
gdb_regformat() current_gdbarch=c9de00 numregs=58 regno=0 fm=0x78
gdb_regformat() current_gdbarch=c9de00 numregs=58 regno=1 fm=0x78
...
gdb_regformat() current_gdbarch=c9de00 numregs=58 regno=55 fm=0x78
gdb_regformat() current_gdbarch=c9de00 numregs=58 regno=56 fm=0x78
Notice something calls deprecated_current_gdbarch_select_hack, which
calls architecture_changed_event, then something calls
setup_architecture_data.
I think architecture_changed_event OUGHT to call
setup_architecture_data, but I can't tell from the source code what it
actually does or who calls setup_architecture_data.
Then notice the second time that deprecated_current_gdbarch_select_hack
is called it still calls architecture_changed_event, but nothing calls
setup_architecture_data, so the data structures are still allocated for
50 registers, but now there are 58.
The registers 0 through 56 get their formats set, trashing regtype,
which as I expected does follow regformat in memory.
The question of what is supposed to call setup_architecture_data
on/after that second call to deprecated_current_gdbarch_select_hack is
way beyond both my understanding of the GCC source code and my ability
to debug things by adding printf's.
next prev parent reply other threads:[~2008-09-17 19:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-18 20:53 John Fine
2008-09-18 21:19 ` Keith Seitz
2008-09-18 21:37 ` John Fine
2008-09-19 7:26 ` Keith Seitz
2008-09-19 14:27 ` John Fine
2008-09-19 18:47 ` Keith Seitz
2008-09-18 22:11 ` John Fine
2008-09-18 22:27 ` John Fine
2008-09-18 23:04 ` Keith Seitz
2008-09-18 23:25 ` John Fine [this message]
2008-09-19 8:20 ` Keith Seitz
2008-09-19 13:27 ` John Fine
2008-09-19 16:38 ` Keith Seitz
2008-09-20 21:22 ` John Fine
2008-09-22 18:35 ` John Fine
2008-09-19 2:17 ` Keith Seitz
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=48D15FD3.8020802@verizon.net \
--to=johnsfine@verizon.net \
--cc=insight@sourceware.org \
--cc=keiths@redhat.com \
/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).