[RFA] solib-svr4.c fetch link map address

[Elena Zannoni]

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