From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7724 invoked by alias); 29 Apr 2003 13:27:15 -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 7716 invoked from network); 29 Apr 2003 13:27:12 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 29 Apr 2003 13:27:12 -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 JAA21542; Tue, 29 Apr 2003 09:25:08 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id JAA14370; Tue, 29 Apr 2003 09:27:10 -0400 Message-ID: <024001c30e53$0fcccba0$0202040a@catdog> From: "Kris Warkentin" To: "Andrew Cagney" Cc: "Gdb@Sources.Redhat.Com" , References: <020701c30dc3$bd8cf020$0202040a@catdog> <3EAD9BB8.8050205@redhat.com> Subject: Re: problem with fetch_link_map_offsets Date: Tue, 29 Apr 2003 13:27: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-04/txt/msg00321.txt.bz2 > > All of a sudden I'm getting a complaint about "No shared lib support for > > this OS/ABI" from the new svr4_have_link_map_offsets function. When I > > initialize my backend tdep file, I set the fetch_link_map_offsets function. > > If I break on svr4_fetch_link_map_offsets, the first couple times I see that > > flmo is set to my function, then the third time it's been set back to > > legacy_fetch_link_map_offsets. I set a break on > > set_solib_svr4_fetch_link_map_offsets and see it being called with my > > function but it never gets called again between when I set it and when it > > shows up as changed. > > > > Can someone tell me where to set a watchpoint to catch the gdbarch data > > being set? I'm still a little shakey on how that all works. > > An aside, "set debug arch 1", and watch to see if any other > architectures are being initialized or selected. Wow...talk about verbosity. At least now I've ruled out any other arches being selected. I was pretty sure that they weren't because I had set a break on set_solib_svr4_fetch_link_map_offsets and it was only called by us. Since that's the only interface to change the lmo function, it would seem like it has to be happening in the solib-svr4.c file somewhere. That's why I was hoping to set a watchpoint. cheers, Kris