This is an archive of the discontinued LLVM Phabricator instance.

[DWARF5] Added support for debug_macro section parsing and dumping in llvm-dwarfdump.
ClosedPublic

Authored by SouraVX on Jan 21 2020, 2:00 AM.

Details

Summary

Summary:
This patch adds parsing and dumping DWARFv5 macro section in llvm-dwarfdump, it does not introduce any new switch. Existing "--debug-macro" can be used to dump macinfo/macro section.

Diff Detail

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
jhenderson added inline comments.Mar 11 2020, 3:03 AM
llvm/test/DebugInfo/X86/debug-macro-v5.s
2

Same comments apply in this test as in the previous one.

Also, use single or double dashes consistently for the entire llvm-mc call.

SouraVX marked 19 inline comments as done.Mar 11 2020, 5:05 AM

Something you may wish to consider is writing the tests as unit tests rather than using dwarfdump to test them, since the code is in a library. It may require a little extra legwork to set up initially (writing dwarf generator code, like there already is for debug info and debug line), but I think there is a decent payoff in return. It'll allow you to avoid the noise that some of these tests have.

Nice suggestion thanks!, but I think that should be taken as a separate exercise. what's your take on this?

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
449

Thanks! for the suggestion here. I've partially tried to address concern related to this also in this inline comment.

These three functions all look very similar..

859

Since these are mostly 5 liner functions handling their cases cleanly as needed, introducing one more function just to reduce 2-3 LOC doesn't sound good idea(personal opinion).
Plus problem in this entire patch(due to code shared by macro/macinfo) is that, you flip one thing and you'll endup modifying everything (handling macro/macinfo, parsing/dumping) just to make sure that existing functionality is not broken.

llvm/test/DebugInfo/X86/debug-macro-macinfo.s
9

emission of DW_FORM_define_strp form is getting checked here. Is this what you're asking ?

31–40

Yes, If Flags in Macro header indicate debug_line_offset is present then it is needed. That's why here.

46

Yes, macinfo section represent this way, If accidentally removed would result in assmbler error.

56–64

Sorry this one is not needed, removed thanks!

SouraVX updated this revision to Diff 249591.Mar 11 2020, 5:07 AM
SouraVX marked 5 inline comments as done.

Addressed review comments by @jhenderson. Thanks a lot for this!

SouraVX added inline comments.Mar 11 2020, 5:12 AM
llvm/test/DebugInfo/X86/debug-macro-v5.s
12

I tried multiple times, but seems like this line is causing the test case to fail when using --strict-whitespace with FileCheck Even though indentation is correct(2 spaces) checked through normal dumping on stdout and by redirecting to a file.
So I temporarily removed --strict-whitespace option. Still digging will update here once done.

SouraVX marked 11 inline comments as done.Mar 11 2020, 5:18 AM
SouraVX added inline comments.
llvm/test/DebugInfo/X86/debug-macro-macinfo.s
50

In editor it was looking normal *No extra space/character*. I'll check once more.

SouraVX updated this revision to Diff 249601.Mar 11 2020, 6:06 AM

Added descriptive comments in test cases.

SouraVX updated this revision to Diff 250036.Mar 12 2020, 1:24 PM

Addressed @jhenderson comments.
Thanks for this!

SouraVX marked 2 inline comments as done.Mar 12 2020, 1:25 PM
SouraVX added inline comments.
llvm/test/DebugInfo/X86/debug-macro-v5.s
12

Added -strict-whitespace option. Thanks!

SouraVX marked an inline comment as done.Mar 12 2020, 9:25 PM

@ikudrin and @jhenderson I've tried to address most of your comments/concerns. Are you guys Okay with these changes?

Something you may wish to consider is writing the tests as unit tests rather than using dwarfdump to test them, since the code is in a library. It may require a little extra legwork to set up initially (writing dwarf generator code, like there already is for debug info and debug line), but I think there is a decent payoff in return. It'll allow you to avoid the noise that some of these tests have.

Nice suggestion thanks!, but I think that should be taken as a separate exercise. what's your take on this?

As it could simplify the tests for this, it might be better to do that upfront. You could then keep a basic test to show that llvm-dwarfdump can dump both kinds of sections, but the detail could be tested in the unit tests. I don't feel strongly about it however.

llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h
32

Still missing a blank line between Version and the comment for flags.

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
859

The flip side argument is that you'd have to modify 3 functions any time you wanted to change the functionality somehow. It's not really about the number of lines of code. I'm not sure sharing the code is that hard. See semi-pseudo code below.

template <typename DWARFDebugT, typename SectionT>
static Expected<const DWARFDebugT *> getDWARFDebugMacro(
           std::unique_ptr<DWARFDebugT> &MacroPtr,
           SectionT *MacroSec,
           bool LittleEndian,
           bool IsMacro,
           DataExtractor StringExtractor) {
  if (MacroPtr)
    return MacroPtr.get();
  DWARFDataExtractor Data(MacroSec, LittleEndian, 0);
  MacroPtr.reset(new DWARFDebugT());
  if (Error Err = MacroPtr->parse(StringExtractor, Data, IsMacro))
    return std::move(Err);
  return MacroPtr.get();
}

Expected<const DWARFDebugMacro *> DWARFContext::getDebugMacinfoDWO() {
  return getDWARFDebugMacro(MacinfoDWO,
                            DObj->getMacinfoDWOSection(),
                            isLittleEndian(),
                            /*IsMacro=*/false,
                            getStringExtractor());
}

...
llvm/lib/DebugInfo/DWARF/DWARFDebugMacro.cpp
56–65

I wasn't interested in the quotes. I wanted you to change the comment to match what I posted, so that it is good English!

130

Nit: "FIXME: Add..." (with space after the ':')

llvm/test/DebugInfo/X86/debug-macro-macinfo.s
2–3

In new tests, I try to use '##' to distinguish comments from lit and FileCheck directives.

can dump debug_macro -> can dump both debug_macro
section -> sections
in a single object -> in the same object

5

This hasn't been done.

5

|\ -> | \ for readability

6

I'd add two extra spaces before llvm-dwarfdump to clearly show that it is a continuation of the previous line.

9

I was just confused by the DW_MACRO_define_strp causing an extra two spaces of indentation, that's all. It looks slightly broken when I read it with little prior knowledge of debug_macro sections.

31–40

Okay. I'd guess that you could delete most of the strings, right?

50

Is it using a tab instead of a space in the text. To me, I see:

.byte  1
.ascii  "DWARF_VERSION"

with the first '"' in the second line not lining up with the 1. I guess you've not written this by hand though, so if this is what the assembler produces, it's fine.

56–64

I was also actually referring to the extra strings. It looks like you've got several duplicates that could be deleted?

llvm/test/DebugInfo/X86/debug-macro-v5.s
8

# CHECK:.debug_macro contents:

same below for the other CHECK: line.

llvm/test/DebugInfo/X86/unsupported-dwarf64-debug-macro-v5.s
2

Same comments in this test as elsewhere re '##', and line continuations.

3

unsupported case where the DWARF64 flag is present in the debug_macro section header.

7

No real need for strict-whitespace and match-full-lines in this test case. The formatting isn't really important.

llvm/test/DebugInfo/X86/unsupported-opcode_operands_table-debug-macro-v5.s
2

Same comments as in other test cases.

We are almost there.

I added comments only for one test file. Please, consider them thoroughly and apply similar adjustments to the other tests.

llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h
87

I suppose it would be useful to add a comment that the value of 0 in Header.Version means that the parsed data is from a .debug_macinfo[.dwo] section and other fields in the Header are uninitialized in that case.

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
855

If you call this method twice, and the first call returns an error, the second call will still return some partially parsed DWARFDebugMacro object. This is inconsistent. You should call Macro.reset() before returning an error.

The same for two other similar methods.

llvm/lib/DebugInfo/DWARF/DWARFDebugMacro.cpp
112

The variable is used only in DW_MACRO_define_strp/DW_MACRO_undef_strp cases. It does not need to preserve the value outside the handler. Thus, why not embrace the body of those cases in braces and move the variable there making it even more local?

llvm/test/DebugInfo/X86/debug-macro-macinfo.s
5

I guess you do not need -dwarf-version=5. It affects the format of the generated .debug_line section, but the parser does not read it and the test does not check anything related to it.

25

You do not need to reference the real line table because it is not used in the parser/dumper. Just use 0 here. And fix the comment.

31–40

Only .Linfo_string3 is used. There are no references to other strings in the file, so they should be removed.

BTW, the comments for the strings are misleading, because all of them except .Linfo_string0 have different offsets than stated.

34

There should be an empty line before .section to improve readability.

43

In fact, this section may be removed because it is not used.

47

Please add comments for this section describing the values, the same way as that is done for .debug_macro.

49

In fact, this definition also does not affect the test and can be removed.

53–56

You may just use .asciz "DWARF_VERSION 4" instead. It is the same but more readable.

59–65

This second .debug_str and all three strings inside it are not needed. Please, remove them.

SouraVX marked 2 inline comments as done.Mar 13 2020, 4:23 AM
SouraVX added inline comments.
llvm/test/DebugInfo/X86/debug-macro-macinfo.s
9

The spacing/indentation is part of dumping here, reflecting that this macro is defined under DW_MACRO_start_file file.

llvm/test/DebugInfo/X86/debug-macro-v5.s
8

Is spacing the you're concerned about here ?

jhenderson added inline comments.Mar 13 2020, 4:35 AM
llvm/test/DebugInfo/X86/debug-macro-v5.s
8

Right. It allows easier reading of the line, because it lines up the actual content being checked with the rest of the content from the subsequent CHECK-NEXT lines.

SouraVX marked 2 inline comments as done.Mar 13 2020, 4:59 AM
SouraVX added inline comments.
llvm/test/DebugInfo/X86/debug-macro-macinfo.s
53–56

Removing this since macinfo represent info in section itself not in debug_str so this is also un-necessary! Sorry for the confusion caused here.
+ Removing other- duplicate/un-necessary string after scrutinizing.

@jhenderson Thanks for sharing pseudo code!
I forgot to mention this thing in our last discussion of refactoring the code shared by macro/macinfo. macro and macinfo are represented differently(due to their contents) to be specific DWARFSection and StringRef explicitly as a result we can't share extract DWARFDataExtractor the using same way. --
DWARFDataExtractor Data(Macinfo, LittleEndian, 0); -- this only works for macinfo
for macro you also need DWARFObject
DWARFDataExtractor MacroData(*DObj, DObj->getMacroSection(), isLittleEndian(), 0); -- only works for macro section.
+ SectionT &MacroSection argument will be const llvm::DWARFSection& -- for macro case
and StringRef --for macinfo case.
code bloating a lot -- psuedo code not compilable, -- sort of need one more extra argument to fetch information from macinfo section (StringRef)

template<typename DWARFDebugT, typename SectionT>
static Expected<const DWARFDebugT*> getDWARFDebugMacro(
                const DWARFObject &DObj,
                std::unique_ptr<DWARFDebugT> &MacroPtr,
                SectionT &MacroSection,
                bool LittleEndian,
                bool IsMacro,
                DataExtractor StringExtractor) {
        if (MacroPtr)
           return MacroPtr.get();
        if (IsMacro) {
        DWARFDataExtractor MacroData(DObj, MacroSection, LittleEndian, 0);
            if (Error Err = MacroPtr->parse(StringExtractor, MacroData, IsMacro)) {
                    Macro.reset();
              return std::move(Err);
            }
        else {
        DWARFDataExtractor MacinfoData(MacroSection, LittleEndian, 0);
        MacroPtr.reset(new DWARFDebugT());
            if (Error Err = MacroPtr->parse(StringExtractor, MacinfoData, IsMacro)) {
                    Macro.reset();
              return std::move(Err);
            }
        return MacroPtr.get();

        }
        }
}

Do you still vote for this ? Please share!

This might be a legacy thing, but it looks like DWARFSection is just a wrapper around a StringRef. Could they all use StringRef (or DWARFSection), instead of having some use one and some use the other? That might require an additional change or two, but it seems pointless having the two types to me.

This might be a legacy thing, but it looks like DWARFSection is just a wrapper around a StringRef. Could they all use StringRef (or DWARFSection), instead of having some use one and some use the other? That might require an additional change or two, but it seems pointless having the two types to me.

The rationale behind putting some section as StringRef and some as DWARFSection is based on relocations macinfo doesn't have relocation macro does have relocations hence (I represented it that way).
DWARFDataExtractor also seems to have different handling(2 constructors) for both cases(relocation and normal cases).
Besides your suggestion to use one common thing(taking StringRef for this case) for both(macro/macinfo) will introduce inconsistency(might also introduce some bugs). Since their are already some sections str line_str and more represented as StringRef while others as DWARFSection.

SouraVX added inline comments.Mar 13 2020, 8:06 AM
llvm/test/DebugInfo/X86/debug-macro-v5.s
8

To avoid same mistakes again, and avoiding confusion -- Following modification you're suggesting -

# CHECK:.debug_macro contents: -- CHECK pattern(1 leading space) in all test cases
should modified be modified with "2" leading spaces in all test cases i.e
# CHECK:debug_macro
and like wise in subsequent CHECK-NEXT ?

SouraVX updated this revision to Diff 250369.Mar 14 2020, 11:05 AM
SouraVX retitled this revision from [WIP][DWARF5] Added support for debug_macro section parsing and dumping in llvm-dwarfdump. to [DWARF5] Added support for debug_macro section parsing and dumping in llvm-dwarfdump..
SouraVX marked 37 inline comments as done.Mar 14 2020, 11:14 AM

Addressed @ikudrin and @jhenderson comments!
Removed [WIP] from Title of the revision!

SouraVX updated this revision to Diff 250371.Mar 14 2020, 11:19 AM
SouraVX marked an inline comment as done.
SouraVX added inline comments.
llvm/test/DebugInfo/X86/debug-macro-macinfo.s
5

Done!

jhenderson added inline comments.Mar 16 2020, 3:28 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h
88

parsing a macinfo...
it self -> itself

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
855

This sort of change is exactly why I think we should avoid duplicating the logic in three places. It would have been easy to add it only in one place.

llvm/test/DebugInfo/X86/debug-macro-macinfo.s
3

Still need to do "the same object" instead of "the single object".

3

I don't see a verbose case still?

llvm/test/DebugInfo/X86/debug-macro-v5.s
8

Thanks, this bit looks fine now.

llvm/test/DebugInfo/X86/unsupported-opcode_operands_table-debug-macro-v5.s
3

where the opcode_operands_table

SouraVX marked an inline comment as done and an inline comment as not done.Mar 16 2020, 3:36 AM
SouraVX added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h
88

Is it okay to keep it the way it self or something like "macinfo or macinfo.dwo section".
Since this also covers macinfo.dwo case also. ?

llvm/test/DebugInfo/X86/debug-macro-macinfo.s
3

I think we don't need one "verbose" case, since there is no difference b/w both cases.

SouraVX marked an inline comment as done.Mar 16 2020, 3:38 AM
SouraVX added inline comments.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
855

I'm investigating the opportunity you discussed/mentioned in last comment(Thanks for that!) If found with constructive cases, will push a patch or two for review.

SouraVX updated this revision to Diff 250515.Mar 16 2020, 4:03 AM

Addressed nits comments by @jhenderson
Thanks for this!

SouraVX marked 3 inline comments as done.Mar 16 2020, 4:03 AM
ikudrin added inline comments.Mar 16 2020, 7:19 AM
llvm/test/DebugInfo/X86/debug-macro-macinfo.s
39

Remove this .file line. I guess you may expect it to contribute the "File Numer" to this section, but that is not true. It has no influence on the content of this section.

In fact, the byte you described as "DW_MACINFO_define" is the actual file number. The next byte is that directive and the following byte is the line number for the entry. You should know that DW_MACINFO_define does not have an operand for file number.

I guess it would be better to use some different values for the file number and for the line number here to avoid that misinterpretation.

43

You may just use .asciz "DWARF_VERSION 4". It is the same. The fact that the macro string consists of the name, space, and value is not important for this test. And you have not divided the definition for "DWARF_VERSION 5" despite it follows the same rules.

llvm/test/DebugInfo/X86/debug-macro-v5.s
32

Not needed for the test. Remove.

llvm/test/DebugInfo/X86/unsupported-dwarf64-debug-macro-v5.s
14

For the consistency, this should be .quad, not .long.

ikudrin added inline comments.Mar 16 2020, 7:20 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
855

This sort of change is exactly why I think we should avoid duplicating the logic in three places. It would have been easy to add it only in one place.

Totally agree.

SouraVX updated this revision to Diff 250567.Mar 16 2020, 8:30 AM

Addressed @ikudrin nits comments. Thanks for this!

SouraVX marked 4 inline comments as done.Mar 16 2020, 8:31 AM
SouraVX marked an inline comment as done.Mar 16 2020, 8:38 AM
SouraVX added inline comments.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
855

I already had discussion with @jhenderson WRT to this in previous revision, highlighted some of the implications https://reviews.llvm.org/D73086#1921493
+ I'm separately investigating that.

SouraVX added inline comments.Mar 16 2020, 9:24 AM
llvm/test/DebugInfo/X86/debug-macro-macinfo.s
43

And you have not divided the definition for "DWARF_VERSION 5" despite it follows the same rules.

Are you concerned regarding representation ??
DW_MACRO_define_strp forms requires the entire macro and definition(value) "DWARF_VERSION 5" to be kept as a string in debug_str section.
That's what I've done here. Am I missing something here ?

jhenderson added inline comments.Mar 17 2020, 2:35 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h
88

Sorry, macinfo[.dwo] was fine (I wanted to correct the like of 'a'). Feel free to reinstate that bit.

llvm/test/DebugInfo/X86/debug-macro-macinfo.s
3

Does verbose mode dump at a different time for .debug_macro etc, like the .debug_line code does? If it does, we should probably still have it (but obviously it can share the same checks).

SouraVX marked 4 inline comments as done.Mar 17 2020, 3:36 AM
SouraVX added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h
88

Sure will do!

SouraVX added inline comments.Mar 17 2020, 3:36 AM
llvm/test/DebugInfo/X86/debug-macro-macinfo.s
3

No, Verbose mode isn't part of macro/macinfo since the beginning. I think it's due to nature of it's contents.

ikudrin marked an inline comment as done.Mar 17 2020, 4:20 AM

I am mostly OK with the changes at the moment. Please reach the consent with @jhenderson about code duplication and other topics he mentioned.

llvm/test/DebugInfo/X86/debug-macro-macinfo.s
43

Both strings, "DWARF_VERSION 4" and "DWARF_VERSION 5", are OK now.

48

Remove the comment "string offset=149". It is both useless and misleading. The real offset is 0.

SouraVX marked 2 inline comments as done.Mar 17 2020, 5:38 AM

I am mostly OK with the changes at the moment. Please reach the consent with @jhenderson about code duplication and other topics he mentioned.

Thanks for the consent @ikudrin!
@jhenderson, Are you okay with these changes?

I am mostly OK with the changes at the moment. Please reach the consent with @jhenderson about code duplication and other topics he mentioned.

Thanks for the consent @ikudrin!
@jhenderson, Are you okay with these changes?

You said you'd take a look at removing the duplication. Have you done that yet? That's what I'm waiting on.

You said you'd take a look at removing the duplication. Have you done that yet? That's what I'm waiting on.

Oh, Sorry! I think I mentioned that should be taken separately. https://reviews.llvm.org/D73086#1921509

You said you'd take a look at removing the duplication. Have you done that yet? That's what I'm waiting on.

Oh, Sorry! I think I mentioned that should be taken separately. https://reviews.llvm.org/D73086#1921509

If you want to do it separately, please do it before this patch. This patch makes the situation worse, which is obviously bad.

SouraVX updated this revision to Diff 250862.Mar 17 2020, 12:40 PM

Refactored to remove code duplication.

Hi @jhenderson, @ikudrin, @dblaikie , I've refactored the dumping code to use a single getDWARFDebugMacro function for all dumping related to macro/macinfo. Thus removing all three redundant dumping functions getDebugMacro/Macinfo/MacinfoDWO . Resultant code looks cleaner/uniform.
@jhenderson I've briefly tried to work on https://reviews.llvm.org/D73086#1921509, hitting up multiple issues, Since this is not just macro/macinfo, a whole lot of sections are represented as DWARFSection and StringRef. This invites a huge rework.

SouraVX updated this revision to Diff 250988.Mar 17 2020, 10:13 PM

Refactored static helper function(dumping macro/macinfo/macinfo.dwo) as a member function, making code more concise.

dblaikie added inline comments.Mar 17 2020, 10:45 PM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
295–297

Returning a pointer to the parameter seems unnecessarily confusing - just return Error instead of Expected - callers can use the MacroPtr they passed in instead of retrieving the same thing from the return value.

301

Prefer make_unique:

MacroPtr = std::make_unique<DWARFDebugMacro>();
302–308

This probably shouldn't be dynamically allocated either - if DWARFDataExtractor is move constructible, which I guess it should be, then:

DWARFDataExtractor Data = IsMacro ? DWARFDataExtractor(... ) : DWARFDataExtractor(...);

If DWARFDataExtractor can't be move constructible then Optional<DWARFDataExtractor> could be used:

Optional<DWARFDataExtractor> Data;
if (IsMacro)
  Data.emplace(...);
else
  Data.emplace(...);
310–311

This doesn't look like it needs to be dynamically allocated - could it just be:

DWARFDataExtractor DataDWO(Context.getDWARFObj().getMacinfoDWOSection(), IsLittleEndian, 0);
314

Rather than nulling out this pointer - use a local unique_ptr and assign to MacroPtr at the end if no errors have occurred. (safer than trying to remember/make sure all the failure paths undo the work)

SouraVX updated this revision to Diff 250997.Mar 17 2020, 11:35 PM

Addressed refactoring comments by @dblaikie. Thanks for this!
-Returned type changed to Error.
-Since DWARFDataExtractor is move constructible, removed dynamic construction of objects.
-Instead of resetting ptr, used local unique_ptr this will get moved to MacroPtr in case of successful parsing.

SouraVX marked 5 inline comments as done.Mar 17 2020, 11:37 PM
dblaikie added inline comments.Mar 18 2020, 1:06 PM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
464

This (& similar elsewhere) should be written as "Macinfo->dump(OS)", the ".get()" is redundant.

@jhenderson - did you want to roll the error handling/dumping into the common code too? (looks like the "if/handle/else/dump" could go in the common function (& rename the function to parseAndDump or something) too?

SouraVX added inline comments.Mar 19 2020, 6:21 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
464

Should we go ahead with this ?

Sorry, I've been quite busy with having about 15-20 different active reviews at once, some of which are not trivial in complexity. It may take me a couple of working days to respond to things.

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
297–298

It might make the code nicer if IsDWO and IsMacro are folded into one small enum e.g. MacroSecType. You can then switch on that value, and it also avoids multiple boolean arguments, which are easy to get wrong.

314

It looks to me like @dblaikie wanted the MacroPtr = std::make_unique<DWARFDebugMacro>(); line to be replaced with auto Ptr = std::make_unique<DWARFDebugMacro>(); and only assign to MacroPtr at the end.

If there is an error, then MacroPtr will remain unchanged (i.e. unitialised). This is very similar to having a strong exception safety guarantee in concept, i.e. the state hasn't changed if there's an error.

464

Since this is all within the same library, we can put the recoverable error handler calls inside the function, and simplify the interface further.

@dblaikie's first comment about get though should also be addressed.

SouraVX updated this revision to Diff 251744.Mar 20 2020, 1:16 PM

Addressed comments/suggestion by @jhenderson and @dblaikie. Thanks a lot for this!
-Removed both boolean types and introduced new helper enum MacroSecType. Now content parsing/dumping is based on this enum.
-Simplified interface further by moving Error handling inside function, renamed this function as parseAndDumpMacroMacinfo.

SouraVX marked 3 inline comments as done.Mar 20 2020, 1:17 PM
jhenderson added inline comments.Mar 23 2020, 2:51 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
284

Dump -> dump a

and macinfo -> or macinfo

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
327–329

Comment indentation is slightly off. Might be worth reporting a warning in the case that this is hit?

465

I'm not particularly keen that dumping and parsing happen in the same function. It feels like those are two separate tasks that should be kept independent. Perhaps a small lambda near here instead would make sense to factor out the sequence "parse -> check not null -> dump"?

SouraVX added inline comments.Mar 23 2020, 4:27 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
465

Are you suggesting something sort of -
parseMacroOrMacinfo handles parsing and error handling, this can be a member function instead of a lamba for uniformities sake.

if (shouldDump(Explicit, ".debug_macro", DIDT_ID_DebugMacro,
                  DObj->getMacroSection().Data)) {
     parseMacroOrMacinfo(Macro, OS, DumpOpts, /*IsLittleEndian=*/true,
                              dwarf::Macro);
     if (Macro)
     Macro->dump(OS);
   }

I'm okay with this too :)

jhenderson added inline comments.Mar 24 2020, 2:29 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
465

Most of the other sections have a pattern of "get/parse" followed by "dump", often in one line, without the error check. I think we should follow that if possible (but with the error check, or possibly by initialising the pointer to some "default" empty section in the event of a failure). In other words, yes, esssentially what you suggested. In particular, this will allow the parsing code to be used and tested independently of the printing.

SouraVX added inline comments.Mar 24 2020, 2:45 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
327–329

Before revising this patch, I want to have your opinion on this -
I'm considering removing this case MacroDWO instead of emitting a warning(I'm not against it). But since that part of code case(MacroDWO) will never be hit, since we don't do it explicitly in first place here --

if (shouldDump(Explicit, ".debug_macro.dwo", DIDT_ID_DebugMacro,
                 DObj->getMacroDWOSection()))
parseMacroOrMacinfo(MacroDWO, OS, DumpOpts, /*IsLittleEndian=*/true,
                              dwarf::MacroDWO);

And it's not needed atleast for this patch.
Should I go ahead remove this case and just leave a FIXME?

jhenderson added inline comments.Mar 24 2020, 3:17 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
327–329

If the behaviour from prior to your patch is unchanged, I think that's fine to do from my point of view. I wouldn't want to see things regress though.

SouraVX updated this revision to Diff 252256.Mar 24 2020, 3:38 AM

Addressed @jhenderson comments, Thanks a lot for this!

  • Refactored the code based on comments.
  • Empty case MacroDWO: is still there with FIXME, just for appeasing a build warning warning: enumeration value ‘MacroDWO’ not handled in switch [-Wswitch]
  • No regression found after check-all.

FIXME: might still look a bit misplaced(couple of spaces), but clang-format is doing that.

SouraVX marked 2 inline comments as done.Mar 24 2020, 3:40 AM
jhenderson accepted this revision.Mar 25 2020, 1:56 AM

LGTM, with one minor suggestion. It might make sense to get one of the other reviewers formal approval before landing this.

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
327–329

I think the problem is that you've put the FIXME above the case statement, whereas it should be below it. If you move it to before the break, it'll look right, and it's probably the right place for it:

case dwarf::MacroDWO:
  // FIXME: Add support for debug_macro.dwo section.
  break;

It might make sense to get one of the other reviewers formal approval before landing this.

Given @ikudrin requested changes earlier, he'll need to approve it for this patch to move to "Approved" state officially, not that it matters that much.

It might make sense to get one of the other reviewers formal approval before landing this.

Given @ikudrin requested changes earlier, he'll need to approve it for this patch to move to "Approved" state officially, not that it matters that much.

Thanks a lot @jhenderson, for investing time in this!
I'll land this after other reviewers @ikudrin and @dblaikie acceptance.

SouraVX marked 2 inline comments as done.Mar 25 2020, 7:21 AM
SouraVX added inline comments.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
327–329

Sure Thanks!
I'll take care of that!

ikudrin added inline comments.Mar 26 2020, 5:05 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
449

I am not sure that Macro as an in-out parameter of a void method is the perfect design. It would be better if parseMacroOrMacinfo() would just return std::unique_ptr<DWARFDebugMacro>. The code here, in that case, will look like:

if (!Macro)
  Macro = parseMacroOrMacinfo(...);
if (Macro)
  Macro->dump(OS);

Much more clear, no?

458–462

Before the patch, isLittleEndian() was used, but now you always pass the constant true. Could you please elaborate, why the behavior has been changed?

SouraVX updated this revision to Diff 252858.Mar 26 2020, 8:35 AM
SouraVX marked an inline comment as done.

Addressed comments by @ikudrin Thanks for this!
-made return type std_unique_ptr<DWARFDebugMacro>.
-littleEndian replaced and some cleanup.

SouraVX marked 3 inline comments as done.Mar 26 2020, 8:38 AM
SouraVX added inline comments.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
449

Removed this

if (!Macro)  --this seemed redundant to me since during first parsing of section, this will always be NULL.
  Macro = parseMacroOrMacinfo(...);
SouraVX marked 2 inline comments as done.Mar 26 2020, 8:43 AM
SouraVX added inline comments.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
458–462

Sorry, some how in effort to keeping the code concise this crept in. I've removed this since parseMacroMacinfo is a member function of DWARFContext.

ikudrin added inline comments.Mar 26 2020, 7:24 PM
llvm/include/llvm/BinaryFormat/Dwarf.h
75 ↗(On Diff #252858)

I guess that it is better to make this enum private inside DWARFContext.

You may also want to remove MACRODWO because it is used only for an empty ("TODO") case in parseMacroOrMacinfo(). Just remove that empty case and move the "TODO" comment to this enum.

llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
276

Maybe I am missing something, but I cannot find the discussion where the removal of these public methods was approved.

getDebugMacinfo() and getDebugMacinfoDWO() should not be removed from the public interface. getDebugMacro() should be added. parseMacroOrMacinfo() should be private and be called from these methods.

SouraVX marked an inline comment as done.Mar 26 2020, 10:09 PM
SouraVX added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
276

It was part of effort of removing the redundant code that @jhenderson and you were discussing about https://reviews.llvm.org/D73086#1927338

SouraVX marked 2 inline comments as done.Mar 26 2020, 10:10 PM
SouraVX added inline comments.
llvm/include/llvm/BinaryFormat/Dwarf.h
75 ↗(On Diff #252858)

Thanks, I'll take care of that in next revision.

SouraVX marked 2 inline comments as done.Mar 28 2020, 1:35 AM
SouraVX added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
276

@ikudrin While naming parseMacroMacinfo or getMacroMacinfo can still be debatable, but semantically this parseMacroMacinfo function is doing essentially the same thing which these 2 + 1(getDebugMacro) were doing i.e parsing the contents and returning to the caller for dumping the contents.

ikudrin added inline comments.Mar 28 2020, 3:24 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
276

Not exactly. Look from the perspective of a user of the DWARFContext class. Before the patch, they could just call Context->getDebugMacinfo(), but now they need to pass way more arguments, some of which are not that obvious (namely, DumpOpts) and others are references to a private member of DWARFContext (namely, MacroPtr). This is a significant degradation of the public interface of DWARFContext.

SouraVX added inline comments.Mar 28 2020, 6:04 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
276

Thanks for pointing this out! I've drafted a rough patch that does not degrade the existing public interface of DWARFContext and doesn't bloat the code too much.
Here's snippet from that, there will be 3 functions(getDebugMacro/Macinfo/MacinfoDWO) calling parseMacroOrMacinfo for doing the math associated with parsing and error handling.

std::unique_ptr<DWARFDebugMacro> DWARFContext::getDebugMacro() {
   return parseMacroOrMacinfo(Macro, getRecoverableErrorHandler(),
              MACRO);
}

In subsequent dumping code we'll just check for nullptr and dump accordingly.

Macro = getDebugMacro();
   if (Macro)
     Macro->dump(OS);

Could you please share your opinion on this!

ikudrin added inline comments.Mar 28 2020, 9:12 PM
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
276

Almost. The getters should cache the result of parseMacroOrMacinfo() and return raw pointers because unique_ptr transfers ownership.

SouraVX updated this revision to Diff 253399.Mar 28 2020, 10:40 PM

Addressed comments by @ikudrin Thanks for this!
-Replaced the return type to raw pointer. Now no un-necessary transfer of ownership involved here.
-Also changed parseMacroOrMacifo to return const DWARFDebugMacro*, in case of errors this will return nullptr. And subsequently checked while dumping.

jhenderson added inline comments.Mar 30 2020, 12:24 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
111–113

Why did you change the naming style of this? LLVM coding standards say that enums should use the same naming scheme as types: https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly.

Also, why the = 1?

114–115

Use C++ style comments, and put this all on one line. Also add missing trailing full stop.

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
300

ParseAndDump. This is a (callable) object, not a function.

SouraVX marked 2 inline comments as done.Mar 30 2020, 1:13 AM
SouraVX added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
111–113

Ah Sorry, I renamed them this way, to avoid confusion of naming while calling
parseMacroOrMacinfo(Macro, getRecoverableErrorHandler(), MACRO);

I'll change this as per Coding Standard.

114–115

Ah, seems like clang-formatting is getting in way(maybe due to /**/ style comment), I'll correct it such that clang-format does't put a new line.

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
300

Sorry, didn't get what you meant here ?

SouraVX added inline comments.Mar 30 2020, 1:27 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
300

Is naming not conforming to standard are you referring here parseAndDump ?

jhenderson added inline comments.Mar 30 2020, 1:46 AM
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
300

Right. Lambdas are objects, not functions, and so should follow the variable naming scheme, not the function naming scheme.

SouraVX marked 3 inline comments as done.Mar 30 2020, 1:56 AM
SouraVX added inline comments.
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
111–113

Just want to drop a forward note here since, naming enum also as Macro Macinfoand so forth was colliding with previous definition std::unique_ptr<DWARFDebugMacro> Macro;
error: Macro conflicts with a previous declaration Macro
So I've extended enum names as
MacroSection MacinfoSection MacinfoDwoSection.

llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
300

Thanks! done locally, we'll wait for @ikudrin before revising this.

ikudrin added inline comments.Mar 30 2020, 2:17 AM
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h
277
  • Make parseMacroOrMacinfo() private.
  • parseMacroOrMacinfo() should return a newly created std::unique_ptr<DWARFDebugMacro>.
  • Remove the MacroPtr argument. Caching the result is the responsibility of getters.
  • Remove the RecoverableErrorHandler argument. All getters pass the same value, and this method, being a non-static member of the same class, also has access to it.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
458–463

This might be simplified to

if (auto Macinfo = getDebugMacinfo())
  Macinfo->dump(OS);
847–862

The getters should look like

const DWARFDebugMacro *DWARFContext::getDebugMacinfo() {
  if (!Macinfo)
    Macinfo = parseMacroOrMacinfo(MACINFO);
  return Macinfo.get();
}
SouraVX updated this revision to Diff 253535.Mar 30 2020, 2:56 AM
SouraVX marked an inline comment as done.

Addressed comments by @jhenderson and @ikudrin Thanks for this!

SouraVX marked 3 inline comments as done.Mar 30 2020, 2:58 AM
ikudrin accepted this revision.Mar 30 2020, 3:30 AM

LGTM. Please wait for the comments from @jhenderson and @dblaikie.

This revision is now accepted and ready to land.Mar 30 2020, 3:30 AM

LGTM. Please wait for the comments from @jhenderson and @dblaikie.

Thanks a lot for investing time in this, I'll wait for @jhenderson and @dblaikie. In meantime can you also share some final thoughts on D72828 Mostly it's already reviewed.

jhenderson accepted this revision.Mar 30 2020, 3:45 AM

Latest version looks good to me too.

@dblaikie are you Okay with these changes ?

dblaikie accepted this revision.Apr 2 2020, 4:38 PM

I think it's OK - best I can tell at this point, given all the review iterations/comments/etc. *fingers crossed*

This revision was automatically updated to reflect the committed changes.