https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94474
--- Comment #11 from Bernd Edlinger <bernd.edlinger at hotmail dot de> --- Andrew, (In reply to Andrew Burgess from comment #10) > Further, I've seen no mention of exit views anywhere, and I think they > would also be needed. > Yes, that is also my idea, when I say the dwarf2 spec needs to be fixed. > With the addition of these two features we would be able to support (I > believe) fully merged callers and callees, with lines marked as > is-stmt from both the caller and callee appearing at the same address. > > For now, without this, I think GCC needs to restrict itself when > inlining. When an address represents a line from both the caller and > callee, then that address should only be is-stmt true for EITHER lines > from the caller, or lines from the callee. If the address is is-stmt > true for a line from the caller, then the address should NOT be within > the callee's range(s), and if the address is is-stmt true for a line > from the callee, then the address MUST be within the callee's > range(s). > I tried to do something similar, in my original gcc-patch, which was unfortunately not accepted. But what I learned from writing the patch is that gcc cannot easily tell if a range will be empty or not. That is because the assembler does emit the line info and the views, and the assembler decides how many bytes if any a certain construct will take in the binary representation. That is why this empty range appears, because that was supposed to be the start of the inline function, but instructions from the function prologue were moved in there. What causes the problem is the is-stmt line info which is the only remaining thing from the original plan. But on the other hand, it is not a big issue for gdb to ignore those artefacts, when they rarely occur. My gdb-patch does this, by changing the is-stmt bit of this line info. > On a final note. These are just my personal thoughts from the > perspective of a debug consumer, though I use words like "must" or > "should" above this reflects my thoughts on how I believe the debug > should appear, and is not an attempt to prescribe how GCC should > be. I know there are limitations to what GCC can achieve, and also, I > could be totally wrong in my understanding of DWARF. I'm always happy > to be corrected! Yeah, that is true for myself as well. Ping, Alexandre Oliva, are you still with us? I would be curious to know what you think, about this how should we proceed? Thanks Bernd.
