This is the mail archive of the
insight@sourceware.org
mailing list for the Insight project.
Re: Can't debug x86_64 C++ programs.
John Fine wrote:
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).
setup_architecture_data is called twice, once on startup (in which case
the architecture is i386 w/50 registers) and then once after "file"
command is issued (when the arch changes to i386:x86_64 w/58 registers)
-- at least it is in my copy. You might be seeing an old bug?
From what I can tell, the change to add the call to
setup_architecture_data was committed on 28 Jun 2007:
2007-06-27 Keith Seitz <keiths@redhat.com>
* generic/gdbtk-register.c (Gdbtk_Register_Init): Remove
calls to deprecated_register_gdbarch_swap.
Add "gdb_reg_arch_changed" command.
* library/regwin.itb (arch_changed): Call gdb_reg_arch_changed.
Is this in your copy of the sources?
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.
The register names all come from gdb. Insight has no specific knowledge
about them. [Remember I said earlier that insight was really ignorant of
architecture-specific things in order to facilitate bring-up of new
architectures? That applies here, too.] Insight gets the list of
registers (and register groups) from gdb directly.
If your copy of the sources contains the patch mentioned above, there
must be another reason for the clobber. Have you tried to "watch" the
memory involved? [If you know the location of a specific clobber, you
can do "watch *0xADDR" to find out what clobbered the memory.] AFAICT,
there is no memory clobber: setup_architecture_data is called on the
architecture_changed_event (albeit in a very obfuscated way for some
reason), it releases the old data and callocs new space.
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?
Yes. The first call is from Gdbtk_Register_Init on startup (arch=i386,
numregs=50). The second time is after the "file" command to load the
x86_64 executable (when arch changes to i386:x86_64, numregs=58).
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?
I would guess that the former is not a problem, gdb/insight is, after
all, just a simple C program. Your target code, though, in C++ w/gcc
3.4.6 is what I would be most suspicious of.
Tomorrow
I'll look into building both Insight and Oprofile with the newer gcc.
If you are just building insight from sources, you can simply set CC in
your environment to use a different compiler from the default one on
your PATH. For example,
$ which gcc
/usr/bin/gcc
$ CC=/home/keiths/work/gcj/built/bin/gcc ../src/configure
[...]
$ make all-gdb
This forces the insight build to use the specified compiler
(/home/keiths/work/gcj/built/bin/gcc) instead of the one in your path
(/usr/bin/gcc).
Don't recall how to do it with oprofile (since oprofile uses C++), but
normally the procedure is similar (although C++ uses a different env var
-- try passing "--help" to oprofile's configure for a list of options).
Keith