Re: gdb doesn't work very well with dynamic linked binaries

[Eli Zaretskii <eliz at delorie dot com>]

> Date: Tue, 5 Sep 2000 15:33:54 +0200 (MET DST)
> From: Mark Kettenis <kettenis@wins.uva.nl>
> 
> 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 think all we need is to store the debug registers somewhere.  They
need to be accessed by (1) the x86-dependent code which is called by
GDB's application level to insert and remove watchpoints; (2) the
target-specific code which actually calls ptrace or the equivalent
syscall to pass the values into the inferior's registers before
resuming it, and set bits after the inferior stops to indicate which
watchpoint(s) triggered; and (3) by stopped_by_watchpoint's target
end.

It's possible that the register cache is as good place as any to store
DRi, even though they slightly differ from the rest of the registers.

> I also couldn't directly see how the hardware watchpoint supports
> interacts with multiple threads

Sorry, I'm not sure I see the problem.  Could you please elaborate?
(I'm afraid I don't know much about Linux threads.)

> especially in presence of the nifty way the go32 code maps multiple
> waitchpoints on a single debugging register.

I don't think this should matter.  The reference counts are just a
means to know which register is used and which isn't.  As far as the
higher-level GDB code is concerned, what's important is (a) which
address, if any, triggered a watchpoint; and (b) which thread caused
the watchpoint to trigger.

However, if I'm missing the point, and there's some additional
infrastructure that is required to make this work with multiple
threads, please tell what is, or might be, missing.

> 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.

If v5.1 freeze date is far away, and if the current code in go32-nat.c
is good enough to be used by other x86 platforms, I might take the
silence as a sign of agreement, given the fact that making it happen
is easy... ;-)