Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Elena Zannoni <ezannoni@redhat.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: Elena Zannoni <ezannoni@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] solib-svr4.c fetch link map address
Date: Wed, 02 Oct 2002 11:42:00 -0000	[thread overview]
Message-ID: <15771.15719.561755.720532@localhost.redhat.com> (raw)
In-Reply-To: <1021002172805.ZM23452@localhost.localdomain>

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


  reply	other threads:[~2002-10-02 18:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-01 19:30 Elena Zannoni
2002-10-01 21:52 ` Daniel Jacobowitz
2002-10-02  6:50   ` Elena Zannoni
2002-10-02 10:28 ` Kevin Buettner
2002-10-02 11:42   ` Elena Zannoni [this message]
2002-10-02 18:45   ` Elena Zannoni
2002-10-02 20:24     ` Kevin Buettner
2002-10-02 21:28       ` Daniel Jacobowitz
2002-10-21 11:43 ` Elena Zannoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15771.15719.561755.720532@localhost.redhat.com \
    --to=ezannoni@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox