This is the mail archive of the
insight@sourceware.org
mailing list for the Insight project.
Re: Can't debug x86_64 C++ programs.
You're obviously doing something very different to cause the
gdbtk_architecture_changed than any of the things I've tried. I don't
know whether that is a factor in your getting to setup_architecture_data.
I still haven't ever gotten to setup_architecture_data from anywhere
other than the initial direct call from Gdbtk_Register_Init.
No matter what I do, setup_architecture_data is called exactly once per
run of insight and that is for the architecture with fewer registers.
After the source and compiler change described below, I tried using the
-nx switch to select the image first from the command line (rather than
from the .gdbtkinit file). That changed the way the backtrace looked
when gdbtk_architecture changed was reached, but it still didn't match
what you had and didn't call setup_architecture_data. So I used -nx and
I didn't put the file on the command line, but selected it instead from
the File menu. That changed that backtrace even more but still nothing
like your backtrace and still didn't call setup_architecture_data.
I kludged numregs in setup_architecture_data to be a larger value, so
this bug no longer corrupts memory. But I've run out of things to try
to even look for the real bug. I was hoping when I found that bug, it
would explain some of the other ways in which insight apparently works
for you and breaks for me. But this one seems to be at least as hard to
look for as those would be.
I stopped using sources from the bz2 file for insight 6.8 and instead
used cvs from :pserver:anoncvs@sourceware.org:/cvs/src because the
source line numbers in the backtrace you sent didn't fit the source
files in 6.8. Changing sources significantly changed the behavior
around gdbtk_architecture_changed, but it still didn't make that call
anything that reaches setup_architecture_data.
I also changed compilers from gcc 3.4.6 to gcc 4.1.2. I don't know
whether that fixed anything in insight itself. Clearly, it makes a
significant difference in the program being debugged by insight. At the
moment, the program I'm debugging most in insight is insight itself.
Lots of things that were broken when the insight being debugged was
compiled with gcc 3.4.6 work much better when the insight being debugged
is compiled with gcc 4.1.2. I don't think any of that is affected by
which compiler was used for the insight doing the debugging.
But even with the target compiled with gcc4.1.2 (and with the kludge to
avoid that memory clobber) lots of things are still broken.
I mainly want to debug C++ compiled with Intel 10.0, so the fact that
insight mostly works for C code compiled with gcc 4.1.2 only helps me
use insight to debug itself, it doesn't get me to debugging anything I
want to debug.
I do understand most of those issues are gdb, not insight. I hate
joining yet another mailing list, but if I get too deep into these bugs,
I guess I'll need to find and join a gdb mailing list.
On the architecture changed issue, I'm ready to give up. I think the
memory clobber was the only consequence and I kludged around that. So
if you have a great suggestion for tracking it down, I'll give it a
try. But otherwise I'm going to go on to issues for which I have even
less idea where to look.
Keith Seitz wrote:
The convoluted path is something like this:
architecture changed event fired from gdb
-> event callback to gdbtk_architecture changed (in C)
--> fires architecture changed event in the Tcl interpreter
---> calls every window's arch_changed method (in Tcl)
----> register window calls gdb_reg_arch_changed (a Tcl command)
-----> gdb_reg_arch_changed is actually aliased directly to
set_architecture_data (see Gdbtk_Register_Init where
'gdb_reg_arch_changed' is registered with the Tcl interpreter)