RE: [PATCH 2/2] gdb/testsuite: Accept PIE/noPIE programs in gdb.mi/mi-var-invalidate-shlib.exp

["Six, Lancelot via Gdb-patches" <gdb-patches@sourceware.org>]

[Public]



> -----Original Message-----
> From: Tom de Vries <tdevries@suse.de>
> Sent: 03 August 2022 13:51
> To: Six, Lancelot <Lancelot.Six@amd.com>; gdb-patches@sourceware.org
> Cc: lsix@lancelotsix.com
> Subject: Re: [PATCH 2/2] gdb/testsuite: Accept PIE/noPIE programs in
> gdb.mi/mi-var-invalidate-shlib.exp
> 
> [CAUTION: External Email]
> 
> On 8/3/22 11:35, Six, Lancelot wrote:
> > [AMD Official Use Only - General]
> >
> >> Hi,
> >>
> >> thanks for the analysis.
> >>
> >> After looking into this a bit, I wonder if the root cause is really
> >> looking at the values in the old process.
> >>
> >> Maybe we should either:
> >> - not try to sample the values when recreating, or
> >> - move the recreation to a later point when we have access to the memory
> >>     of the new process.
> >>
> >> At least we would have consistency between PIE and no-PIE with either
> >> solution.
> >>
> >> Thanks,
> >> - Tom
> >
> > Hi,
> >
> > I do agree that it is strange to look for a value for the new objfile in the old
> process.  I wonder if there are legitimate usecases where one would want to
> still use "file ..." to load new symbols but keep the same process running
> while keeping a global varobj around.  If we delay the recreation of the
> varobj, we would break such usecase.
> >
> 
> You're right,  apparently that's a valid use case.
> 
> > One way could be to be just invalidate the varobj when the objfile it relies
> on goes away and give the user a "-var-reinflate" command (or "-var-update
> -reinflate") so he can try to revive an invalidated varobj at his convenience.
> This would break existing behavior but could avoid.
> 
> I've now reached the conclusion that the bug is merely that for
> recreating the varobjs we don't wait until relocation has happened, as
> we do for breakpoints.
> 
> This WIP patch delays recreation of the varobj to the point that the
> file command has relocated the PIE exec.
> 
> This makes behaviour equal between PIE and no-PIE (meaning we see the
> same two FAILs now for gdb.mi/mi-var-invalidate-shlib.exp).
> 
> I'm not sure about the split between invalidate and re_set, I'm not
> familiar with this code.
> 
> WDYT?

Hi

This looks the way forward!

It looks like to me that varobj_invalidate_iter (and varobj_invalidate) can go away entirely.
The only thing they do is invalidate locals which are still valid at this point, and I think this
is not what we want:

- If the varobj was tracking a local which was associated with the objfile being replaced, then
  `varobj_invalidate_if_uses_objfile` would have set the is_valid flag to false earlier when unloading
  the previous objfile.
- If the varobj is tracking a local in another objfile which is still loaded, I do not see why we would invalidate it.
  It is possible to have such scenario with the mi-var-invalidate-shlib example: if stopped in the shlib and create
  a varobj to track a local variable, there is no reason for a "file mi-var-invalidate-shlib" to invalidate it.

Also seeing this makes me wonder if varobj_re_set_iter should only try to re-inflate invalidated globals.  I do not
see why a "file" has to force a "-var-update" on floating varobj, but I need to think a bit more about this one.

Lancelot.

> 
> Thanks,
> - Tom