Hi Andrew, and Tom I'll try to help, if I can. I must admit I was busy with other things, so I have not much new info, but I can add my view. First I want to make you aware, of my last e-mails on this issue, I wonder if you got them. I added Alexandre Oliva who maintains the debug info in GCC to CC then, and unfortunately although I was hoping that he gives his view on this matter, I think I have not received any response from him so far. https://sourceware.org/pipermail/gdb-patches/2020-April/167933.html https://sourceware.org/pipermail/gdb-patches/2020-April/167932.html I must note that it is impossible to find out the e-mail addresses which were in CC on the mailing list archives since the unfortunate move to the new maling list archive format. But I added oliva@gnu.org in CC, probably you should do that as well, since I think we cannot get anything changed in the gcc debug output unless we can convince him about it. Andrew, as far as I remember the range info of the inlined subroutines were not correct, in your patch. GCC tells us where the code originating from the inlined code starts and ends. The byte addresses. These must be the same addresses where the line numbers switch from the calling procedure to the inlined procedure but the range info in your dwarf code is artificially and it is having start and end addresses where they should be. Can you please fix the range infos in your patch and re-post it, before we decide how to proceed? I will probably not have time to do much today, since this is my son's birthday, and I will probably bake a birthday cake instead :-) But I would say that I see a way how I can adjust my patch to fix the issues which were raised by your test case (I added the test case from your patch to mine, and most of it seems to be fine with my latest patch, one remaining issue is a bit nasty but fixable). I'll attach the patch file where I am at here, so you can see what I have now. It fails only one test case in dw2-inline-header-3.exp but I would like how it compares to your patch when Tom would like to try it out on the internal test cases, he mentioned. And, yes, of course my approach is that the debug info is not optimal at all as it is emitted by gcc, but gdb can probably work around it until it is fixed which should happen when a new updated dwarf extension is invented which tells us the view number where the inlined subroutine ends. The line table program has view numbers, but not the range info of the subroutine. That is the deficiency in the dwarf format I think causes the trouble, apart from the fact that dwarf is already too complicate to understand. I must also say, that since if I remember correctly Andrew's patch makes gdb.cp/step-and-next-inline.exp fail, I consider my attempt to make gdb work around the debug info of inlined subroutines a failure. While my patch did make gdb.cp/step-and-next-inline.exp succeed completely, also the case where the inline function is not in a header file. I must also say, and that is not because I have emotions about it, but just because I consider it the only possible option when we consider gcc's debug output format completely broken, then I will probably just send a one-line patch to gcc-patches, which reverts the default of -gstatement-frontiers, that would be safe for backporting to all active branches. And it would prevent the !is_stmt line infos completely, the debug format will then probably work as before gcc-8 implemented that for the first time. So I attached my latest patch version, together with the Test case from Andrews patch. 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 still think this is possible, I think we need to understand each other better. Of course stress from release cycles might this even harder. Are we (gdb maintainers) already under stress to reach the next release version? >> Andrew> I don't know how we address this without merging your patch, >> Andrew> releasing GDB and seeing how it works in the wild. However, if we >> Andrew> did decide to "just try it", I would still prefer we staged things >> Andrew> as: >> Andrew> (a) Merge my patch, targeted regression fix, then >> Andrew> (b) Your patch, new functionality GCC/DWARF ranges work around. >> Andrew> In this way, if we end up backing out some or all of (b) we still >> Andrew> have (a) in place that fixes the regression. I'm more than happy >> Andrew> for a rebase of (b) in include full removal of (a). >> >> I think landing your patch is safe to do while we discuss part (b). >> How about we move forward with that part? Then if we come to agreement >> on where the bug lies we can decide about that. > > I agree. I already rebased this and retested it. Unless someone > shouts out between now and tomorrow I plan to merge my patch. > > Bernd (or anyone else) - I'm more than happy that if a better patch is > put forward it can revert some or all of my patch, as needed. Like > Tom, I'd like to see the regressions squashed. > No, I am not able to do this once we decide that gcc's debug info is impossible to implement, I will send a patch to the gcc-patches which restores the gcc-7 debug info. My patch was based on the assumption that there is a way to work around the issues, but if that turns out to be a failure, I will not go back and revert your patch again, since it seems to revert my work on that issue completely (see how this patch breaks the step-and-next-inline.exp test case). And once again, I feel not at all emotional, just that I want the issue fixed, and next time I will try a completely different approach which is gcc was wrong, and therefore we will revert Alexandre Oliva's patch, since it is the least effort and Alexandre already signaled he also had considered that already. Alexandre Oliva wrote on 11/19/19: https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534845.html > Perhaps we should change our defaults, if the situation with GDB does > not change :-( Andrew: Have you attached your *latest* patch? Have you done the changes I requested? Thanks Bernd.