Hi Tom, Andrew, > On 5/15/20 12:39 AM, Andrew Burgess wrote: >> * Tom Tromey [2020-05-14 14:18:44 -0600]: >> >>>>>>>> "Andrew" == Andrew Burgess writes: >>> >>> Resurrecting this again ... we have some internal tests that have been >>> failing, and I want to land at least one of these patches to resolve >>> this. >>> >>> Andrew> After reading[2] I'd also be interest to understand what flaw in >>> Andrew> DWARF you feel makes a difference in this case. >>> >>> I also don't understand this. >>> > > When you only know where an inline function ends at the byte address. > You can habe line table entries at the same address from the inline > funcion and from the calling function. It is impossible to distinguish > between those, however there is a view number which would be different, > and as Alexandre explains it, these can be consider an extension to the > byte addresses, so if a range info would add a view number we would > know which line infos are from the subroutine and which are not, even > if the byte addresses are identical. > >>> Andrew> I think it is great Bernd, that you are reaching out from the GCC >>> Andrew> community to engage with GDB, this is certainly the best way to ensure >>> Andrew> that we can work together as communities to give the best possible >>> Andrew> debug experience, and I'm sorry you feel that I have not been clear >>> Andrew> enough about the issues I'm seeing here. >>> >>> +1 >>> I am always happy to help. Andrew, and/or Tom, could you please test my patch, obviously one new test case is still failing, however I would not rule out the possibility, that we can work together to even fix that, I must say that our cooperation made things possible, that I would not have expected, like fixing the inline functions that are not in a header file. How does this patch work in practice, I would be happy to know what I have to fix even when Andrews patch lands tomorrow, probably due to a release schedule? Attached are again the patch from myself, and test cases from Andrew's patch. By the way when is the next gdb release planned? And let me say this, honestly, I am happy to take the blame for any GCC BUG :-), that certainly still exists, and ideally those will be fixed in a way that gdb can figure out that it is fixed, ideally by some kind of dwarf-version info in the debug info. What is a given thing that this broken debug info is already there for years, and historic gcc version will continue to exist for quite a while. So my goal is to work around it, communicate with each other, look for solutions, but not make the users unhappy unless absolutely necessary. Thanks Bernd.