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?

Thanks,
- Tom