This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb doesn't work very well with dynamic linked binaries
Date: Tue, 5 Sep 2000 06:35:52 -0400 (EDT)
From: Eli Zaretskii <eliz@delorie.com>
> Date: Mon, 4 Sep 2000 23:32:22 -0700
> From: "H . J . Lu" <hjl@lucon.org>
>
> If you can generalize it for ia32, I will implement it for Linux/ia32.
The code on go32-nat.c manipulates an array which represents the ia32
debug registers, including the status and control registers. It
leaves it to resume() and its subroutines on the target end to
actually insert the watchpoints when the inferior is resumed and
remove them when the inferior stops and control is passed to GDB.
If this model suits most or all ia32 targets, pulling the code from
go32-nat.c into a separate module (probably, as part of i386-nat.c)
would be very easy for me. If not, I'd ask the relevant maintainers
to tell what provisions should I make for other platforms to fit in.
I looked into the the hardware watchpoint support some time ago, and
actually started coding, seperating the generic bits out of the go32
code. I was thinking of having some sort of register cache for the
debugging registers but didn't immedeately see the right solution to
do that. Perhaps they should simply be added to the register cache?
I also couldn't directly see how the hardware watchpoint supports
interacts with multiple threads, especially in presence of the nifty
way the go32 code maps multiple waitchpoints on a single debugging
register.
In principle I see no reason why x86 hardware waitchpoints couldn't be
implemented by i386-tdep.c though.
> If it won't be fixed in 5.1, I will follow your hints and implement a
> Linux only solution when it happens to me again.
A generic x86 solution would be preferable, but a clean, well
documented Linux-only solution is certainly welcome.
I can do this Very Soon (tm) provided that I hear a GO from The Powers
That Be. Andrew? Stan? What say you?
> Hardware watchpoints
> have been known to be broken on Linux/ia32 for a long time and nothing
> has been done to it.
Apparently nobody cares enough. It isn't at the top of my priority
list so if nobody else contributes the necessary code, it probably
won't happen in the near future.
Mark