From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26621 invoked by alias); 7 Jun 2011 16:29:35 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 26607 invoked by uid 22791); 7 Jun 2011 16:29:32 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org From: Tom Tromey To: archer@sourceware.org Subject: Re: gdb side of improved linker-debugger interface References: <20110607094808.GB4143@redhat.com> Date: Tue, 07 Jun 2011 16:29:00 -0000 In-Reply-To: <20110607094808.GB4143@redhat.com> (Gary Benson's message of "Tue, 7 Jun 2011 10:48:08 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2011-q2/txt/msg00016.txt.bz2 >>>>> "Gary" == Gary Benson writes: Gary> A week or so ago I mailed this list a description of a new linker- Gary> debugger interface based on SystemTap probes, along with a patch Gary> 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'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. Gary> I've seen mention that the RT_CONSISTENT called too early bug was the Gary> cause of another issue where libthread_db would not be loaded if Gary> libpthread was loaded with dlopen rather than being linked in, but I Gary> haven't been able to discover if this really was ever the case. If Gary> anybody knows (or has a testcase) could 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. 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. Once the patch is ready I think it should go on archer-sergiodj-stap and then on origin/archer-sergiodj-stap-patch-split as the last patch in the series. 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. 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. Tom