From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7616 invoked by alias); 9 Jul 2003 20:00:25 -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 7591 invoked from network); 9 Jul 2003 20:00:24 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 9 Jul 2003 20:00:24 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id PAA14047; Wed, 9 Jul 2003 15:51:38 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id QAA18524; Wed, 9 Jul 2003 16:00:23 -0400 Message-ID: <0a2d01c34654$ccf74460$0202040a@catdog> From: "Kris Warkentin" To: "Daniel Jacobowitz" Cc: "Kevin Buettner" , "Andrew Cagney" , "Gdb@Sources.Redhat.Com" References: <087801c34630$479de310$0202040a@catdog> <20030709162430.GA20778@nevyn.them.org> <090201c3463f$acc520f0$0202040a@catdog> <1030709174134.ZM2191@localhost.localdomain> <093901c34642$884d0280$0202040a@catdog> <095501c34644$31dec7b0$0202040a@catdog> <20030709180553.GA23828@nevyn.them.org> <099e01c34646$ea45e4d0$0202040a@catdog> <20030709183041.GA24498@nevyn.them.org> <09d201c3464e$2011b290$0202040a@catdog> <20030709194608.GA25806@nevyn.them.org> Subject: Re: [rfc] Print solib events in mi-mode Date: Wed, 09 Jul 2003 20:00: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.1165 X-SW-Source: 2003-07/txt/msg00113.txt.bz2 > > The other is just to compare against a dll_pathname so we could get away > > with creating a SOLIB_WAS_(UN)LOADED(pid, "libname") and have the backend > > check through the list for libname. > > Sure. Or return a list and let solib.c sort between 'em. Do you think these functions should be in current_target_so_ops? > > Okay...that seems reasonable. Another question: since we've already got a > > solib breakpoint set in svr4, we don't need to call > > create_solib_load_event_breakpoint() like somsolib.c and pa64solib.c do. > > Can you have multiple types associated with a single break or do we just set > > another at the same address? > > It should be multiple "catchpoints", and inserting catchpoints would do > nothing to the target. This may require violence to the breakpoint > system, which is why I haven't done it yet :( You're suggesting a list of gdb "actions" associated with a single breakpoint on the target? IE, test for a condition, execute a catch, check solibs on the target, etc.? Kris