From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26800 invoked by alias); 15 Oct 2003 18:21:39 -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 26784 invoked from network); 15 Oct 2003 18:21:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 15 Oct 2003 18:21:38 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9FILcM06033 for ; Wed, 15 Oct 2003 14:21:38 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9FILWr11619 for ; Wed, 15 Oct 2003 14:21:32 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9FILWwC009125 for ; Wed, 15 Oct 2003 14:21:32 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 4E1982C43E; Wed, 15 Oct 2003 14:32:53 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16269.37588.478658.637269@localhost.redhat.com> Date: Wed, 15 Oct 2003 18:21:00 -0000 To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: SOFUN_ADDRESS_MAYBE_MISSING In-Reply-To: <200310061242.h96CgtiA000454@elgar.kettenis.dyndns.org> References: <200310061242.h96CgtiA000454@elgar.kettenis.dyndns.org> X-SW-Source: 2003-10/txt/msg00202.txt.bz2 Mark Kettenis writes: > I'm wondering what to do with SOFUN_ADDRESS_MAYBE_MISSING. It started > out (and still largely is) a hack to work around a problem with > stabs-in-ELF with Sun's C compiler. Later it also got enabled on some > Linux variants, to work around a bug in HJ's Linux binutils IIRC. > > The safest thing to do is probably to turn this into a multi-arch > variable, and set that variable for all targets that #define > SOFUN_ADDRESS_MAYBE_MISSING. I winder however, what the impact would > be of enabling this on all ELF targets, since that would make it > easier to debug object modules created with the Sun compiler to > FreeBSD/sparc64 for example. > > Mark [odd, this thread seems to have not been archived in sources.redhat.com/ml/gdb] Let me take a different view on this. The definitions of SOFUN_ADDRESS_MAYBE_MISSING are on ppc/linux, i386/linux, i386/solaris2, sparc/solaris2, and deal with problems with the stabs debug info. However, i386/linux now uses dwarf2, and so does ppc/linux. Can anybody reproduce the original problem with shared libraries, which appears to have been the motivation behind defining SOFUN_... on the Linux platforms? I tried *deleting* the definition of SOFUN_ADDRESS_.. in config/i386/tm-linux.h, and I ran the testsuite both on a stabs platform (RH 7.3) and a dwarf2 platform (RH 9) and found no differences in the testsuite results, before and after the change (of course there are the usual differences between the stabs and the dwarf2 runs). Anyway, at closer inspection, and looking back: There has been some discussion one year ago about this. http://sources.redhat.com/ml/gdb-patches/2002-04/msg00836.html A couple of patches were contributed towards elimination of the macro, but we ended up committing only one of them. Summarizing, at that time, Kevin raised the objection that enabling the SOFUN code everywhere may make us lose the ability to have symbols at address 0. Is this still a concern for some embedded targets? From the old thread it appears that it was decided it was an acceptable risk. The approach we were converging upon at that time was to do a 2 phase checkin, the first to eliminate the macro from symmisc.c, symtab.h, minsyms.c. This would require to increase the size of a minsym in all cases, by making this unconditional: #ifdef SOFUN_ADDRESS_MAYBE_MISSING /* Which source file is this symbol in? Only relevant for mst_file_*. */ char *filename; #endif However, looking at the code as it is now, it seems that the old thread was partially wrong about how to deal with this. The filename information is used in 3 functions in minsym.c which have ifdef SOFUN_ code: lookup_minimal_symbol_text: the SOFUN_.. code deals with the second parameter (if not null). However there are 4 calls to this function, and none of them passes a non-null 2nd parameter. I think we can get rid of these, i.e. delete the code that is ifdeffed. lookup_minimal_symbol_solib_trampoline: Again, deal with cases where the second parameter is non-null. However, the function never really does anything with the second paramter. And this lonely ifdef can go. In any event, there are 4 calls to this function, and all pass NULL as 2nd parameter. lookup_minimal_symbol: Again, deal with the 2nd parameter being non-null. This is called in a few places in dbxread.c with non null 2nd paramter. I don't think this SUFUN_.. code can be eliminated yet. So, I think I'll clean up the code that can be cleaned up, and then take a look again. In the meantime if somebody could verify that defining the macro has no impact on Linux, that would also give us a better picture. elena