From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23721 invoked by alias); 11 Jun 2003 19:05:37 -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 23687 invoked from network); 11 Jun 2003 19:05:37 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 11 Jun 2003 19:05:37 -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 OAA18864; Wed, 11 Jun 2003 14:59:28 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id PAA05136; Wed, 11 Jun 2003 15:05:33 -0400 Message-ID: <0a4201c3304c$786134b0$0202040a@catdog> From: "Kris Warkentin" To: "Kris Warkentin" , Cc: "Kevin Buettner" , "Gdb@Sources.Redhat.Com" References: <200306101012.h5AAClK01881@pc960.cambridge.arm.com> <047001c32f4a$d31eead0$0202040a@catdog> <050801c32f60$21211d10$0202040a@catdog> Subject: Re: problem with fetch_link_map_offsets Date: Wed, 11 Jun 2003 19:05: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-06/txt/msg00189.txt.bz2 Okay. Looks like this fix only works for arm. All the targets seem to call the sniff function but at some point, the current_gdbarch is changing and the fetch_link_map_offsets is pointing back to legacy_fetch_link_map_offsets. I've been stepping through all over the place and looking through the output of set debug arch 1 and still not finding what I'm looking for. The nearest guess I can make is that somewhere in gdbarch_update_p, gdb is creating a new gdbarch which is much like the one that I initialized but not quite. I have these nto_init_abi functions that are registered to the bfd and tied to GDB_OSABI_QNXNTO. Gdbarch_update_p is creating a new gdbarch, filling in some fields, tagging it with GDB_OSABI_QNXNTO and carrying on. Then things fall apart because the new gdbarch has lost my fetch_link_map_offsets pointer and current_gdbarch->data[1] is pointing back to the legacy_flmo. Argh. All I'm doing in my tdep init sections are things like this: gdbarch_register_osabi (bfd_arch_sh, 0, GDB_OSABI_QNXNTO, shnto_init_abi); Then my init_abi function sets things up with calls to set_solib_svr4_fetch_link_map_offsets and the like. Am I doing something wrong? It almost looks like things need to happen in a different order or the init function needs to be called again or something. Any ideas? cheers, Kris > Here's a fix that works right now: If I put the code below into > generic_elf_osabi_sniff_abi_tag_sections(), the sniffer does its job. The > problem with this is that it will only work on dynamically linked binaries. > Convenient as a stop-gap and for a certain amount of backwards > compatability. I think the .note.qnxnto.ident section is still a good idea > though. I tried putting one into our crtbegin.o but then programs were core > dumping so I'm doing something wrong there. I'll have to talk to the OS > folks. > > cheers, > > Kris > > /* QNX Neutrino has ldqnx.so as its linker. */ > if (strcmp (name, ".interp") == 0 && sectsize > 0) > { > char *buf = alloca(sectsize); > bfd_get_section_contents(abfd, sect, buf, 0, sectsize); > buf[sectsize] = '\0'; /* Safety first boys and girls. */ > if(strstr(buf, "ldqnx.so")) > *os_ident_ptr = GDB_OSABI_QNXNTO; > return; > } > > >