There are no FileCheck checks for the new metric, as far as I can tell?

In D82975#2152631, @dstenb wrote:

What do you think about the patch series as it stands now, @SouraVX?

Thanks a lot for the perseverance reviewing this, @dblaikie!

Fall back to the macinfo format for split DWARF, and add a test case for that.

Assert on split DWARF.

Rebase and address review comments.

In D82975#2139704, @dblaikie wrote:

(Sorry, I don't have a GCC trunk build readily available, so I used GCC 9.3.0 here.)

When using those flags, GCC seems to emit DW_MACRO_define_strp (DW_MACRO_GNU_define_indirect) entries, but with indexed strings as operands. Neither binutils nor GDB does consider that such entries may hold indexed strings, and just treats those operands as indirect strings, which is why they are not properly handled. "Overloading" those indirect operands with indexed strings seems very weird to me. Perhaps that is just a bug in GCC, rather than a limitation in the consumers?

Perhaps - though there was some thought put into supporting GNU debug_macro in v4/pre-standard Fission, given the DWP format had columns for both debug_macro and debug_macinfo ( https://gcc.gnu.org/wiki/DebugFissionDWP ). Don't think it's a big deal either way - if someone comes along wanting to add debug_macro support for pre-standard Fission, we can discuss what that format looks like at that point - happy enough for it to be unimplemented (& as I said before, have "-ggdb -gdwarf-4 -fdebug-macro -> debug_macro" and "-ggdb -gdwarf-4 -fdebug-macro -gsplit-dwarf -> debug_macinfo.dwo").

Could you please add a paragraph to the summary that explains why this change is done?

In D82975#2135150, @SouraVX wrote:

In D82975#2134626, @dblaikie wrote:

In D82975#2134347, @probinson wrote:

In D82975#2134132, @dblaikie wrote:

In D82975#2128353, @dstenb wrote:

In D82975#2127201, @SouraVX wrote:

I think if it's about compatibility(analogous behavior with GCC), existing infra is Okay/Fine(Since same encodings are used). We just need to emit the .debug_macro section with version 4 and teach the llvm-dwarfdump to parse it correctly.

One difference though is that the GNU extension does not have anything like the strx entries that LLVM currently emits: https://github.com/gcc-mirror/gcc/blob/master/include/dwarf2.h#L425, so I assume we still need code to emit the strp entries when targeting DWARF 4?

Likely - but might want to check what GCC does - maybe it uses some kind of strx encoding that's not documented, etc.

My recollection is that .debug_macro was invented independently of the strx forms so the prototype probably wouldn't have used them. Easy enough to check whether GCC's -fdebug-macro with v4 is emitting a .debug_str_offsets section.

LLVM wouldn't be using strx forms from .debug_info for v4, and would have no other reason to emit .debug_str_offsets, so I wouldn't want LLVM to use them in a v4 compatibility mode .debug_macro section either.

GCC certainly seems to produce some kind of debug_macro.dwo section (& binutils dwp supports it in the index, if I recall correctly) using some form llvm-dwarfdump currently doesn't understand:

$ g++-tot -g3 main.cpp -c -gsplit-dwarf && llvm-objdump -h main.dwo | grep " \.debug"
  1 .debug_info.dwo        0000003c 0000000000000000 
  2 .debug_abbrev.dwo      0000003e 0000000000000000 
  3 .debug_macro.dwo       0000001e 0000000000000000 
  4 .debug_macro.dwo       00000364 0000000000000000 
  5 .debug_macro.dwo       00000013 0000000000000000 
  6 .debug_line.dwo        00000048 0000000000000000 
  7 .debug_str_offsets.dwo 000002d5 0000000000000000 
  8 .debug_str.dwo         00000e05 0000000000000000 
$ llvm-dwarfdump-tot main.dwo -debug-macro
main.dwo:       file format elf64-x86-64

.debug_macro.dwo contents:
0x00000000:
 - lineno: 19 macro: 
DW_MACINFO_invalid

I mean, I don't have strong feelings about supporting macro debug info in general, but if someone feels strongly about debug_macro GNU extension DWARFv4 support, there's certainly some GCC behavior that one could use to model the Split DWARF support for that off.

One more deciding factor to considered here(previously missed) is that: GDB(trunk) also doesn't understand GNU macro extensions(if you wish to call it) in split case.
i.e
gcc -g3 -gsplit-dwarf test.c
test.dwo contains .debug_macro.dwo forms which no tool(as of now can dump).
if you load a.out in GDB and try expanding macro(defined in source).
GDB will report

(gdb) info macro FOO
The symbol `FOO' has no definition as a C/C++ preprocessor macro
at <user-defined>:-1

on the other hand, if you try with -gstrict-dwarf -gsplit-dwarf. GDB is happy.
So at the end of the day, even if we allow GNU macro extension, things will still be broken for -gsplit-dwarf case.
Or we have to teach the debugger to understand this ?, this also hinges on the fact, what kinda form GCC uses in split-case in .debug_macro.dwo section.
That it self is unclear right ?

In D82975#2134132, @dblaikie wrote:

In D82975#2128353, @dstenb wrote:

In D82975#2127201, @SouraVX wrote:

When you say 'by default' - do you mean by default when the user requests macro debug info (via -fdebug-macro) or by default without any extra flag?
& what does GCC do? Does it have a way to emit the standard debug_macinfo in v4 and below? Or does it always emit the debug_macro GNU extension?

I'm not particularly sure of this(introduction of GNU encodings). Behavior of GCC trunk(11.0.0) is as follows:

gcc -g3 test.c -c, after dumping using objdump(2.32), GCC will create .debug_macro(sort of it's default, until you specify -gstrict-dwarf in which case GCC will generate .debug_macinfo).

As Sourabh says this is default when not emitting strict DWARF in GCC. For Clang, my intention was for it to be enabled by default for -fdebug-macro when tuning for GDB. Maybe it would also be interesting when tuning for LLDB?

Sounds alright. Not sure if the LLDB folks (@aprantl @JDevlieghere @labath) would be interested in that - a separate patch in any case.

Rebase and address comment.

Address comments.

In D82972#2127215, @SouraVX wrote:

Do we really need this ?, Please have a look at https://sourceware.org/legacy-ml/gdb-patches/2017-02/msg00528.html
IMO, it would be unwise to commit it till the discussion thread in D82975 converges ?

In D82975#2127201, @SouraVX wrote:

When you say 'by default' - do you mean by default when the user requests macro debug info (via -fdebug-macro) or by default without any extra flag?
& what does GCC do? Does it have a way to emit the standard debug_macinfo in v4 and below? Or does it always emit the debug_macro GNU extension?

I'm not particularly sure of this(introduction of GNU encodings). Behavior of GCC trunk(11.0.0) is as follows:

gcc -g3 test.c -c, after dumping using objdump(2.32), GCC will create .debug_macro(sort of it's default, until you specify -gstrict-dwarf in which case GCC will generate .debug_macinfo).

Thanks, and sorry for letting this patch lay dormant. I'll land this tomorrow when I have time for the build bots.

LGTM. Sorry for the delay!

Minor comments. Looks good to me otherwise!

In D78107#2029294, @ntesic wrote:

In beginInstruction() guard we should expect that delay slot instruction is immediately after call instruction, before label insertion.
In constructCallSiteEntryDIEs() guard we should expect that both the call instruction and its successor are followed by the same label.

@dstenb @vsk @djtodoro Thanks for your comments and, please,
let me know what do you think about this approach.

Do you need help with landing this?

I have a comment about the CHECK/PARSER test cases. Otherwise this looks good to me.

Thanks!

One minor comment about singular/plural phrasing. Otherwise this looks good to me!

In D75270#2012177, @djtodoro wrote:

Hi @dstenb,

What is the status with this?

Two minor nits, but otherwise this looks good to me. Thanks!

Adding a nit. I'll try to take a closer look at the functionality later today.

In D75326#1926466, @dstenb wrote:

Yeah, sure! I can put together a mail for the mailing list today or tomorrow.

Rebase on top of D76423. Add a test that verifies that the operation is emitted correctly in location lists. Without D76423 this patch would simply emit a DW_OP_convert with the first base type in ExprRefedBaseTypes, rather than 0x0.

This was something I overlooked when implementing D76145.

Thanks for the reviews! I'll land this shortly.

In D76279#1926497, @djtodoro wrote:

LGTM! Thanks!

So, this was causing the wrong call_site_value for the parameter only?

In D75326#1925517, @vsk wrote:

No worries, I think this is great feedback. I think we've just touched on a tricky part of the standard. Do you still have the time to start a discussion about this on the dwarf mailing list?

In D76145#1924795, @aprantl wrote:

Have you thought about doing this

In D76146#1922222, @aprantl wrote:

Mechanically LGTM to me. I'm not sure if this shouldn't be done in DwarfExpression instead.

Remove binary file from diff due to issues with arc patch. I'll add the file back when landing this, which I plan to do shortly.

In D76164#1922542, @dstenb wrote:

Sorry for taking some extra time with that PR. This patch should fix that assertion, but we would emit invalid debug information, related to D76146, for that case.

In D76164#1922504, @manojgupta wrote:

Can you also test on the reduced test cases in https://bugs.llvm.org/show_bug.cgi?id=45181 ?

In D73534#1918940, @dstenb wrote:

In D73534#1918890, @manojgupta wrote:

Hi,

I see another crash with this change when building gdb.

Reduced test case:
struct type *a(type *, type *, long, long);
enum b {};
static int empty_array(type *, int c) { type *d = a(__null, d, c, c - 1); }
long e;
b f() { empty_array(0, e); }

Repros with:
clang -cc1 -triple x86_64-linux-gnu -emit-obj -disable-free -mrelocation-model pic -pic-level 2 -pic-is-pie -mthread-model posix -mframe-pointer=all -mconstructor-aliases -munwind-tables -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -O2 -x c++

Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1060788

Oh, that assertion is related to D75036 which I did. I can have a look at that.

In D73534#1918890, @manojgupta wrote:

Hi,

I see another crash with this change when building gdb.

Reduced test case:
struct type *a(type *, type *, long, long);
enum b {};
static int empty_array(type *, int c) { type *d = a(__null, d, c, c - 1); }
long e;
b f() { empty_array(0, e); }

Repros with:
clang -cc1 -triple x86_64-linux-gnu -emit-obj -disable-free -mrelocation-model pic -pic-level 2 -pic-is-pie -mthread-model posix -mframe-pointer=all -mconstructor-aliases -munwind-tables -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -O2 -x c++

Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1060788

LGTM

Thanks, this seems like a good workaround to get rid of the assertion until D75326 has landed.

In D75326#1904157, @vsk wrote:

Sorry for the delay here.

@dstenb wrote:

When I print that in GDB 8.2.1, 0x5566 is printed instead of 0x11225566 which is the actual parameter value:

Yeah, this sounds like a debugger bug to me. The debugger should print something that indicates that the upper bits of "param" are unknown. Although, to be fair, lldb has the same bug (or it might be worse, and print out "param" as 0x00005566 -- it doesn't track the bits of a variable that are uncovered by pieces).

The DW_OP_entry_value operation at the callee expects a value to be pushed to the DWARF stack when evaluating the DW_AT_call_value at the caller. How should/would that work with composite descriptions?

Well, in lldb at least, I think the idea is that while OP_piece doesn't push anything to the stack, it changes the debugger's notion of which bits in the evaluated result are "valid". So one way this could work is: the result of evaluating the DW_AT_call_value is pushed onto the stack when evaluating DW_OP_entry_value (and if it's e.g. a 2-byte piece, so be it).

All of which sounds a little iffy to me for what appears to be a pretty uncommon case (fwiw I was able to build all of clang & LNT for x86 without hitting this).

In D75270#1897102, @vsk wrote:

Fixing the assertion failure in this way sgtm. Re:

I dug around some in the Dwarf-discuss archive, and it seems that when working on DWARFv3 the piece operations were moved out from the "Dwarf Expressions" section to "Location Descriptions" to clarify that they don't push anything to the stack.

In D75326#1898465, @vsk wrote:

If OP_piece in an entry value really /is/ an issue, please confirm, and I'll update the x86 describeLoadedValue to just return 'None' for mov{8,16}ri (it doesn't seem worth it to me to do anything more complicated).

In D75326#1898465, @vsk wrote:

In D75326#1898169, @dstenb wrote:

In D75326#1898071, @vsk wrote:

Thank you @dstenb and @djtodoro very much for your feedback.

I think I've addressed the main issue, we now produce DW_AT_call_value (DW_OP_constu 0x840, DW_OP_stack_value, DW_OP_piece 0x2). PTAL.

I might be incorrect here, but I don't think we are allowed to use DW_OP_piece operations in DW_AT_call_value attributes, as they should be DWARF expressions? As far as I have understood it, the DW_OP_piece operation is only allowed in composite location descriptions, and you can in general not go from location descriptions to DWARF expressions, with the only (?) exception being DW_OP_entry_value operations holding register location descriptions.

(This seems a bit related to D75270, in which I stop emitting entry values around composite location descriptions, since the DWARF standard specifies that those are only allowed to hold DWARF expressions and register location descriptions.)

If I understand your reading correctly, it's that composite location descriptions are not (in general) a kind of DWARF expression.

FWIW, this doesn't line up with my understanding. DWARF5 says "a single location description" may be "a composite location description", which consists of "one or more simple location descriptions", each of which describes "one piece of the object" (2.6.1). And it says that a DWARF expression describes "how to compute a value or specify a location" (2.5). That certainly /sounds/ like a composite location can be a DWARF expression.

In D75326#1898071, @vsk wrote:

Thank you @dstenb and @djtodoro very much for your feedback.

I think I've addressed the main issue, we now produce DW_AT_call_value (DW_OP_constu 0x840, DW_OP_stack_value, DW_OP_piece 0x2). PTAL.