This is the mail archive of the
insight@sourceware.org
mailing list for the Insight project.
Re: Can't debug x86_64 C++ programs.
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.