Re: gdb side of improved linker-debugger interface

[Gary Benson <gbenson@redhat.com>]

Tom Tromey wrote:
> >>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:
> 
> Gary> A week or so ago I mailed this list a description of a new
> Gary> linker- debugger interface based on SystemTap probes, along
> Gary> with a patch containing the glibc side:
> Gary>   http://www.cygwin.com/ml/archer/2011-q2/msg00000.html
> 
> If this is ready then the next step is to try to get it into glibc.
> 
> I don't think it can go into glibc mainline, but perhaps we can get
> it onto Roland's branch.
> 
> One thing that would be useful is a write-up explaining the issues
> and why this approach is correct.  What I recall from some bug (I
> don't recall which one) on the topic is that Ulrich was of the
> opinion that the debug hook was in the right spot and that GDB was
> wrong.  It would be good to have a rebuttal for this position in
> particular.

I was thinking about this last night.  What I'm considering is adding
at least one more probe point, so there's one at the original location
(where Uli thinks is right) and one where we actually want to break.
I also want to look into the thing on
https://bugzilla.redhat.com/show_bug.cgi?id=698001#c1 where they
mention calling their function (_dl_debug_fast_state) *only* when the
link map has actually changed as I didn't realise there were
situations where it wouldn't.

> I'm not sure what the protocol is here -- email to glibc-alpha, or
> just to Roland.  glibc-alpha will likely get you flamed, don your
> protective gear.

I emailed Andreas privately a while back and he said to discuss it on
glibc-alpha, so I guess that's the place for this.

> Gary> I've seen mention that the RT_CONSISTENT called too early bug
> Gary> was the cause of another issue where libthread_db would not be
> Gary> loaded if libpthread was loaded with dlopen rather than being
> Gary> linked in, but I haven't been able to discover if this really
> Gary> was ever the case.  If anybody knows (or has a testcase) could
> Gary> you fill me in on it please.
> 
> I failed in my attempt to make a simple reproducer.
> I know David Malcolm had this reliably fail with his Python plugin
> for GCC; so you might try that, though it seems rather large for a
> test case.

I have this now: http://sourceware.org/ml/archer/2011-q2/msg00022.html

> Gary> +  /* SystemTap probes.  */
> Gary> +  const struct stap_probe *pre_mod_probe;
> Gary> +  const struct stap_probe *post_mod_probe;
> 
> You are going to have to merge or rebase and update this a bit.  I
> changed find_probe_in_objfile on the branch, to account for probes
> with multiple locations.

Ok, thanks for the heads up.

> Gary> +static int
> Gary> +svr4_update_solib_event_breakpoint (struct breakpoint *b, void *arg)
> Gary> +{
> Gary> +  struct svr4_info *info = get_svr4_info ();
> Gary> +  struct bp_location *loc;
> Gary> +
> Gary> +  for (loc = b->loc; loc; loc = loc->next)
> Gary> +    {
> Gary> +      if (loc->pspace == current_program_space
> Gary> +	  && loc->address == info->pre_mod_probe->address)
> Gary> +	{
> Gary> +	  b->enable_state = stop_on_solib_events;
> 
> This should have a constant from `enum enable_state' on the RHS.

Ah, ok, I'll change it.  

> Gary> -	  create_solib_event_breakpoint (target_gdbarch, sym_addr);
> Gary> +	  svr4_create_solib_event_breakpoints (target_gdbarch, sym_addr);
> 
> I don't know this code very well, but it seems to me that it is
> looking at different ways to set the solib breakpoints.  Your
> current code runs at the very end -- GDB still tries the existing
> ways to find the breakpoint locations, and then, if one is found,
> instead inserts at the probe point if that is found.
> 
> Assuming this reading is correct, it seems like it would be better
> to just check for SystemTap probe points early in enable_break, and
> then prefer those to the other methods.

I did it that way to ensure we're looking for the probes in the
correct object.  It uses the original code to locate _dl_debug_state,
then assumes that the object containing _dl_debug_state is the linker
and looks for the probes in that.  I don't know if this is the right
solution though.

Cheers,
Gary

-- 
http://gbenson.net/