This is the mail archive of the insight@sourceware.org mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]