From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12827 invoked by alias); 25 Feb 2003 21:36:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12820 invoked from network); 25 Feb 2003 21:36:56 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 25 Feb 2003 21:36:56 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id QAA21283 for ; Tue, 25 Feb 2003 16:24:44 -0500 Received: from dash ([192.168.20.34]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id QAA24800 for ; Tue, 25 Feb 2003 16:36:54 -0500 Message-ID: <016801c2dd16$862cb0d0$2a00a8c0@dash> From: "Kris Warkentin" To: Subject: Re: deferred breakpoints Date: Tue, 25 Feb 2003 21:36:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-02/txt/msg00544.txt.bz2 I took a look at the sources from apple and it looks like what they're doing is relatively simple. I think most of the wiring is already in gdb. 1) Attempt to set break. If that fails: 2) Create a raw breakpoint and set it to be shlib_disabled. That way gdb attempts to reset it every time a shlib is loaded. I believe that you might get a lot of error messages with this method when gdb complains about not being able to set the breakpoints but I may be wrong. The relevant code is below. Interesting. I'll see if I can do it with a newer version (the apple source is for gdb-4.18) cheers, Kris struct symtab_and_line sal = {0, 0}; struct breakpoint *b = set_raw_breakpoint (sal); printf_unfiltered ("Will attempt to resolve \"%s\" on future dynamic loads.\n", args); b->number = ++breakpoint_count; b->addr_string = savestring (args, strlen (args)); b->enable = shlib_disabled; b->inserted = 0; b->disposition = donttouch; b->type = bp_breakpoint; if (modify_breakpoint_hook) modify_breakpoint_hook (b); > How difficult do you think deferred breakpoints would be to implement? We > have a customer who does a lot of work with shared objects and they'd like > to be able to set breakpoints in them and have them persist across runs. > I'm thinking that creating a list of breakpoints that could be run through > every time a shared object was loaded would do the trick. Can anyone point > out any obvious gotcha's? > > Kris >