Re: [PATCH 1/2] Fix BZ 25065 - Ensure that physnames are computed for inherited DIEs

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2019-10-22 6:23 p.m., Kevin Buettner wrote:
> On Fri, 18 Oct 2019 11:07:31 -0400
> Simon Marchi <simon.marchi@polymtl.ca> wrote:
> 
>>> I looked over your patch; it looks reasonable to me.  If we go that
>>> route, I like the idea of introducing a dwarf2_cu_processing_context
>>> struct.  (But see below for some later misgivings that I have/had.)  
>>
>> Ok, I can try to make something cleaner, but I don't know when it
>> would be ready, and I wouldn't want that to block the GDB 9.1 branch
>> creation (or release) for that.  Would you like to still push your
>> patch (or a perhaps updated version of it) so that we have the fix
>> in GDB 9.1?
> 
> [...]
> 
>>> There may be other concerns too; I'm certain that I didn't look at all
>>> of the ways that CU is used in dwarf2_physname and its callees.  
>>
>> I don't think it's humanly possible to manually check all the
>> possible branches this code can take.  I say, let's do a quick pass
>> to check for the obvious (like what you found above), but otherwise
>> I'm fine with this patch, it already makes things better than they
>> are now.
> 
> My testing shows that the patch below still fixes the problem while
> also avoiding the poential problems of passing a CU to
> compute_delayed_physnames() which is different from the CU of the
> methods for which want to compute physnames.
> 
> I think that this patch is safer than the one I originally proposed
> and is, therefore, a better short term solution.
> 
> What do you think?

Yep, this looks good and relatively safe to me.

Thanks!

Simon