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

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Tue, 5 Sep 2000 11:46:48 -0400 (EDT)
   From: Eli Zaretskii <eliz@delorie.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.

Yep, and that's where I got distracted by more urgent problems :-(.

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

Me neither :-(.  I'm not sure whether the debug registers are
per-thread or per-VM-space in Linux.  I'll probably need to look into
the kernel source.

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

If you can set the debug registers per-thread, we might need a
reference count for every thread.  If the debug registers are
per-VM-space there might be a potential problem with finding out the
right triggering address for the right thread.

   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.

It's something that needs to be investigated.  But since DJGPP doesn't
seem to support multiple threads I certainly don't expect you to do
that :-).

Mark