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:
Insight registers gdbtk_architecture_changed as the observer callback.
That's the part I didn't have a clue about, so you've given me at least
the name I can grep for to get a clue.
It calls the proc gdb_reg_arch_changed, which is aliased to the C
function setup_architecture_data. [Phew!] So, alas,
setup_architecture_data *is* being called.
But I had a printf in setup_architecture_data, so I can be quite sure it
is only called the first time (for the architecture with 50 registers)
and it is not called the second time (for the architecture with 58
registers).
I'm a bit confused that i386 has as many as 50 registers and much more
confused that AMD64 has only 8 more than i386. I know for sure about 16
registers that are not in i368 but are part of AMD64 (and are working
correctly in the registers window, now that I kludged around the memory
clobber). But that 58 vs. 50 issue is just idle curiosity. The big
question is how you avoid the memory clobber.
Is setup_architecture_data really called twice for 50 registers the
first time and 58 the second? Or does your copy start in AMD64
architecture? Or does your memory allocation land differently, so the
memory clobber happens without symptom? Or what?
Is the fact that my copy of Insight was built with gcc 3.4.6 more
significant than the fact that some of my target programs were built
with gcc 3.4.6?
The group with which my project needs to keep gcc version compatibility
is about to switch version, I think to 4.1.2. We have that version of
gcc already installed here, but not as the default. I'm not very expert
in Linux. So I know how to pick a non default version of gcc for our
own projects built with bjam, but I don't know how to do it for a source
package like Insight, with its rather complicated makefile. Tomorrow
I'll look into building both Insight and Oprofile with the newer gcc.