Can't debug x86_64 C++ programs.

[John Fine]

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.