From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2807 invoked by alias); 9 Jun 2011 14:26:32 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 2796 invoked by uid 22791); 9 Jun 2011 14:26:31 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,DATE_IN_PAST_24_48,SPF_FAIL X-Spam-Check-By: sourceware.org Date: Thu, 09 Jun 2011 14:26:00 -0000 From: Gary Benson To: Tom Tromey Cc: archer@sourceware.org Subject: Re: gdb side of improved linker-debugger interface Message-ID: <20110608141239.GE2680@redhat.com> Mail-Followup-To: Tom Tromey , archer@sourceware.org References: <20110607094808.GB4143@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SW-Source: 2011-q2/txt/msg00025.txt.bz2 Tom Tromey wrote: > >>>>> "Gary" == Gary Benson 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/