From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8331 invoked by alias); 29 Apr 2003 15:25:40 -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 8324 invoked from network); 29 Apr 2003 15:25:39 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 29 Apr 2003 15:25:39 -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 LAA26496; Tue, 29 Apr 2003 11:23:35 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id LAA06987; Tue, 29 Apr 2003 11:25:38 -0400 Message-ID: <030401c30e63$9c270560$0202040a@catdog> From: "Kris Warkentin" To: "Kevin Buettner" , "Gdb@Sources.Redhat.Com" Cc: References: <020701c30dc3$bd8cf020$0202040a@catdog> <1030429150643.ZM6454@localhost.localdomain> Subject: Re: problem with fetch_link_map_offsets Date: Tue, 29 Apr 2003 15:25: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/msg00326.txt.bz2 > Do you mean that you're calling set_solib_svr4_fetch_link_map_offsets() > from your _initialize_XXX_tdep() function? If so, that's not right. It > should be done either in the ABI initialization function (e.g. see > ppc_linux_init_abi in ppc-linux-tdep.c) or in your XXX_gdbarch_init > function. I'll tell you what I do and you can tell me if I'm right. I have an _initialize_shnto_tdep function in my sh-nto-tdep.c which calls: gdbarch_register_osabi (bfd_arch_sh, 0, GDB_OSABI_QNXNTO, shnto_init_abi) Within shnot_init_abi I have all my set_solib_svr4_fetch_link_map_offsets() and other stuff. When I watch gdb in the debugger, I see that set_svr4_flmo is called twice, both times with my shnot_svr4_flmo function. I also observe that svr4_have_link_map_offsets is called three times in the process of attaching to the remote proces. The first two are fine - flmo is still pointing to the qnx version. The third time it's pointing to the legacy_flmo though. I can't figure out why. > Maybe... > > current_gdbarch->data[fetch_link_map_offsets_gdbarch_data->index] > > ? > > Something like this will probably work if you suspect that it's changing > after the fact. It probably won't work to see it initialized though. > > You may also want to watch current_gdbarch to see when it changes. I > suspect that's the problem. I'll try that. Thanks. Kris