From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18843 invoked by alias); 2 Oct 2002 18:42:03 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18836 invoked from network); 2 Oct 2002 18:42:02 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 2 Oct 2002 18:42:02 -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 g92IN9i08027 for ; Wed, 2 Oct 2002 14:23:09 -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 g92Ig1f05980 for ; Wed, 2 Oct 2002 14:42:01 -0400 Received: from localhost.redhat.com (IDENT:root@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g92Ig0920016; Wed, 2 Oct 2002 14:42:00 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id EBA8EFF79; Wed, 2 Oct 2002 14:39:36 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15771.15719.561755.720532@localhost.redhat.com> Date: Wed, 02 Oct 2002 11:42:00 -0000 To: Kevin Buettner Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] solib-svr4.c fetch link map address In-Reply-To: <1021002172805.ZM23452@localhost.localdomain> References: <15770.22961.366656.980373@localhost.redhat.com> <1021002172805.ZM23452@localhost.localdomain> X-SW-Source: 2002-10/txt/msg00065.txt.bz2 Kevin Buettner writes: > On Oct 1, 10:28pm, Elena Zannoni wrote: > > > + discard_cleanups (old_chain); > > + return lm; > > + } > > + } > > + /* Not the file we wanted, continue checking. */ > > + lm = extract_address (objfile_lm_info.lm + lmo->l_next_offset, > > + lmo->l_next_size); > > + discard_cleanups (old_chain); > > + } > > Why are the cleanups being discarded? Won't this result in a memory > leak? > Whoops, yes. Left over from a previous version of the function. We need to *do* the cleanups before returning, instead. I realized I also need to add to the cleanups the freeing of l_name_buf and buffer... > Another concern is that there appears to be some duplication of code > between svr4_current_sos() and the function that you've just written. > I'm wondering if some sort of factoring could be done to minimize > duplication. > The problem is that I need to check the main executable and not ignore it like the solib stuff does. I tried to not skip the main executable and include that in the list of so's. However that got too convoluted pretty soon, because now all the shlibs ops would require to skip over the main executable. I think I ran into problems because a lot of solib operations assume that there are only solibs in the list. I also didn't like the idea of introducing inconsistencies between svr4 and other flavors. So I didn't pursue it. > Finally, I'm curious about how often we'll be fetching the link > map address. Is it the case that it'll be fetched once (per > objfile) and never fetched again? Or will it be fetched repeatedly? > If it's the former, I think your approach is fine. If the latter, we > should consider saving the link map address so that it can be supplied > to glibc without having to read the target. > It gets triggered by read_var_value when a variable is in thread local storage. So it happens whenever the variable needs to be printed. > Kevin