On Nov 19, 2019, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > My question to you is this: can you explain, given the following debug > info, extracted by readelf from alias.c, why the address 0x6e11 is in > the inlined subroutine and *not* in the get_alias_set function?
The long version of the explanation is in https://www.fsfla.org/~lxoliva/papers/sfn/ The long version is that this extension encodes multiple "source program states" without an intervening instruction. Consider, for example: int f(int x) { int a = x * x; return a; } ... z = 3; y = f(z); Further consider that the function is inlined and everything is optimized to mov ry, 9 We can still encode debug information to the effect that we assigned 3 to z, that we then entered the scope of the inlined function f binding x to 3, that we assigned x * x to a, that we returned it, and that we assigned the result to variable y held in register ry. Without location views, you could encode all of this, but all the debugger would see when you get to the instruction above is that you're past the end of the scope of variables x and a, because f has already returned, and that z holds the value 3 and y still holds whatever value it had before. With location views, you can encode all of these program states at the instruction. Say, you can have a #0 view before the assignment to z, a #1 after the assignment to z, a #2 after entering the inline function f and binding x to z, a #3 after computing a, and a #4 after returning from f, back at the line of the assignment to y. This is realized by outputting multiple views at the same PC, usually for different source locations, and by augmenting location lists with view numbers for each PC in the range, for a finer granularity in specifying the range in which the expression is active. > [0x00008b39] Special opcode 189: advance Address by 13 to 0x6e11 and Line > by 2 to 3388 The above introduces view #0 for PC 0x6e11 > [0x00008b3a] Set is_stmt to 0 > [0x00008b3b] Copy (view 1) and here's view #1 > [0x00008b3c] Set File Name to entry 5 in the File Name Table > [0x00008b3e] Set column to 8 > [0x00008b40] Advance Line by -2549 to 839 and there is presumably a view #2 after this. > 00009d60 0000000000006e00 0000000000006e11 > So I read this: when pc==0x6e11, the location is line 3388 (in tree.h) > it is a statement. But the inlined subroutine "contains_struct_check" > extends from 0x6e00..0x6e11 and from 0x1115..0x112f. Therefore 0x6e11 > is OUTSIDE the subroutine, and that is what the gdb thinks there as > well. Here's one of the points in which having multiple views per PC extends DWARF: ending a code range at 0x6e11 doesn't necessarily mean there isn't any view associated with that function at 0x6e11. In this case, there are, but it's still true that the range ends at that address, because there are other views at that PC that are not part of the function. I realize now that I focused mainly on location lists, thinking the implied scopes could be used to infer the ranges of the enclosing functions, but perhaps aranges should have been augmented with view numbers as well, so as to enable debug info consumers to tell more directly (and precisely) where inlined functions start and end. -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Free Software Evangelist Stallman was right, but he's left :( GNU Toolchain Engineer FSMatrix: It was he who freed the first of us FSF & FSFLA board member The Savior shall return (true);
