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.
Details
Diff Detail
Event Timeline
llvm/test/DebugInfo/X86/debug-macro-v5.s | ||
---|---|---|
1 ↗ | (On Diff #249372) | Same comments apply in this test as in the previous one. Also, use single or double dashes consistently for the entire llvm-mc call. |
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 | ||
---|---|---|
455 | Thanks! for the suggestion here. I've partially tried to address concern related to this also in this inline comment.
| |
850 | 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). | |
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
8 ↗ | (On Diff #249372) | emission of DW_FORM_define_strp form is getting checked here. Is this what you're asking ? |
30–39 ↗ | (On Diff #249372) | Yes, If Flags in Macro header indicate debug_line_offset is present then it is needed. That's why here. |
45 ↗ | (On Diff #249372) | Yes, macinfo section represent this way, If accidentally removed would result in assmbler error. |
55–63 ↗ | (On Diff #249372) | Sorry this one is not needed, removed thanks! |
llvm/test/DebugInfo/X86/debug-macro-v5.s | ||
---|---|---|
11 ↗ | (On Diff #249591) | 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. |
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
---|---|---|
49 ↗ | (On Diff #249372) | In editor it was looking normal *No extra space/character*. I'll check once more. |
llvm/test/DebugInfo/X86/debug-macro-v5.s | ||
---|---|---|
11 ↗ | (On Diff #249591) | Added -strict-whitespace option. Thanks! |
@ikudrin and @jhenderson I've tried to address most of your comments/concerns. Are you guys Okay with these changes?
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 | ||
---|---|---|
30 | Still missing a blank line between Version and the comment for flags. | |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
850 | 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 | ||
52–54 | 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! | |
109–117 | Nit: "FIXME: Add..." (with space after the ':') | |
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
1–2 ↗ | (On Diff #250036) | In new tests, I try to use '##' to distinguish comments from lit and FileCheck directives. can dump debug_macro -> can dump both debug_macro |
4 ↗ | (On Diff #250036) | |\ -> | \ for readability |
5 ↗ | (On Diff #250036) | I'd add two extra spaces before llvm-dwarfdump to clearly show that it is a continuation of the previous line. |
4 ↗ | (On Diff #249372) | This hasn't been done. |
8 ↗ | (On Diff #249372) | 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. |
30–39 ↗ | (On Diff #249372) | Okay. I'd guess that you could delete most of the strings, right? |
49 ↗ | (On Diff #249372) | 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. |
55–63 ↗ | (On Diff #249372) | 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 | ||
7 ↗ | (On Diff #250036) | # CHECK:.debug_macro contents: same below for the other CHECK: line. |
llvm/test/DebugInfo/X86/unsupported-dwarf64-debug-macro-v5.s | ||
1 ↗ | (On Diff #250036) | Same comments in this test as elsewhere re '##', and line continuations. |
2 ↗ | (On Diff #250036) | unsupported case where the DWARF64 flag is present in the debug_macro section header. |
6 ↗ | (On Diff #250036) | 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 | ||
1 ↗ | (On Diff #250036) | 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 | ||
---|---|---|
95 | 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 | ||
846 | 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 | ||
98 | 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 | ||
4 ↗ | (On Diff #250036) | 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. |
24 ↗ | (On Diff #250036) | 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. |
33 ↗ | (On Diff #250036) | There should be an empty line before .section to improve readability. |
42 ↗ | (On Diff #250036) | In fact, this section may be removed because it is not used. |
46 ↗ | (On Diff #250036) | Please add comments for this section describing the values, the same way as that is done for .debug_macro. |
48 ↗ | (On Diff #250036) | In fact, this definition also does not affect the test and can be removed. |
52–55 ↗ | (On Diff #250036) | You may just use .asciz "DWARF_VERSION 4" instead. It is the same but more readable. |
58–64 ↗ | (On Diff #250036) | This second .debug_str and all three strings inside it are not needed. Please, remove them. |
30–39 ↗ | (On Diff #249372) | 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. |
llvm/test/DebugInfo/X86/debug-macro-v5.s | ||
---|---|---|
7 ↗ | (On Diff #250036) | 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. |
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
---|---|---|
52–55 ↗ | (On Diff #250036) | 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. |
@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.
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.
llvm/test/DebugInfo/X86/debug-macro-v5.s | ||
---|---|---|
7 ↗ | (On Diff #250036) | 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 |
Addressed @ikudrin and @jhenderson comments!
Removed [WIP] from Title of the revision!
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
---|---|---|
4 ↗ | (On Diff #249372) | Done! |
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h | ||
---|---|---|
96 | parsing a macinfo... | |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
846 | 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 | ||
2 ↗ | (On Diff #250371) | Still need to do "the same object" instead of "the single object". |
2 ↗ | (On Diff #249372) | I don't see a verbose case still? |
llvm/test/DebugInfo/X86/debug-macro-v5.s | ||
7 ↗ | (On Diff #250036) | Thanks, this bit looks fine now. |
llvm/test/DebugInfo/X86/unsupported-opcode_operands_table-debug-macro-v5.s | ||
2 ↗ | (On Diff #250371) | where the opcode_operands_table |
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h | ||
---|---|---|
96 | Is it okay to keep it the way it self or something like "macinfo or macinfo.dwo section". | |
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
2 ↗ | (On Diff #249372) | I think we don't need one "verbose" case, since there is no difference b/w both cases. |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
846 | 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. |
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
---|---|---|
38 ↗ | (On Diff #250515) | 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. |
42 ↗ | (On Diff #250515) | 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 | ||
31 ↗ | (On Diff #250515) | Not needed for the test. Remove. |
llvm/test/DebugInfo/X86/unsupported-dwarf64-debug-macro-v5.s | ||
13 ↗ | (On Diff #250515) | For the consistency, this should be .quad, not .long. |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
846 |
Totally agree. |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
846 | I already had discussion with @jhenderson WRT to this in previous revision, highlighted some of the implications https://reviews.llvm.org/D73086#1921493 |
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
---|---|---|
42 ↗ | (On Diff #250515) |
Are you concerned regarding representation ?? |
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h | ||
---|---|---|
96 | 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 | ||
2 ↗ | (On Diff #249372) | 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). |
llvm/include/llvm/DebugInfo/DWARF/DWARFDebugMacro.h | ||
---|---|---|
96 | Sure will do! |
llvm/test/DebugInfo/X86/debug-macro-macinfo.s | ||
---|---|---|
2 ↗ | (On Diff #249372) | No, Verbose mode isn't part of macro/macinfo since the beginning. I think it's due to nature of it's contents. |
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 | ||
---|---|---|
47 ↗ | (On Diff #250567) | Remove the comment "string offset=149". It is both useless and misleading. The real offset is 0. |
42 ↗ | (On Diff #250515) | Both strings, "DWARF_VERSION 4" and "DWARF_VERSION 5", are OK now. |
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
If you want to do it separately, please do it before this patch. This patch makes the situation worse, which is obviously bad.
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.
Refactored static helper function(dumping macro/macinfo/macinfo.dwo) as a member function, making code more concise.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
288–290 | 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. | |
294 | Prefer make_unique: MacroPtr = std::make_unique<DWARFDebugMacro>(); | |
295–301 | 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(...); | |
303–304 | This doesn't look like it needs to be dynamically allocated - could it just be: DWARFDataExtractor DataDWO(Context.getDWARFObj().getMacinfoDWOSection(), IsLittleEndian, 0); | |
307 | 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) |
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.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
461 | 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? |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
461 | 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 | ||
---|---|---|
290–291 | 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. | |
307 | 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. | |
461 | 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. |
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.
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
276 ↗ | (On Diff #251744) | Dump -> dump a and macinfo -> or macinfo |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
320–322 | Comment indentation is slightly off. Might be worth reporting a warning in the case that this is hit? | |
458 | 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"? |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
458 | Are you suggesting something sort of - 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 :) |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
458 | 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. |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
320–322 | Before revising this patch, I want to have your opinion on this - 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. |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
320–322 | 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. |
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.
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 | ||
---|---|---|
320–322 | 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; |
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.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
320–322 | Sure Thanks! |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
455 | 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? | |
455 | Before the patch, isLittleEndian() was used, but now you always pass the constant true. Could you please elaborate, why the behavior has been changed? |
Addressed comments by @ikudrin Thanks for this!
-made return type std_unique_ptr<DWARFDebugMacro>.
-littleEndian replaced and some cleanup.
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
455 | Removed this if (!Macro) --this seemed redundant to me since during first parsing of section, this will always be NULL. Macro = parseMacroOrMacinfo(...); |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
455 | 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. |
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 ↗ | (On Diff #252858) | 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. |
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
276 ↗ | (On Diff #252858) | It was part of effort of removing the redundant code that @jhenderson and you were discussing about https://reviews.llvm.org/D73086#1927338 |
llvm/include/llvm/BinaryFormat/Dwarf.h | ||
---|---|---|
75 ↗ | (On Diff #252858) | Thanks, I'll take care of that in next revision. |
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
276 ↗ | (On Diff #252858) | @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. |
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
276 ↗ | (On Diff #252858) | 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. |
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
276 ↗ | (On Diff #252858) | 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. 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! |
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
276 ↗ | (On Diff #252858) | Almost. The getters should cache the result of parseMacroOrMacinfo() and return raw pointers because unique_ptr transfers ownership. |
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.
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
111–113 ↗ | (On Diff #253399) | 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 ↗ | (On Diff #253399) | Use C++ style comments, and put this all on one line. Also add missing trailing full stop. |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
293 | ParseAndDump. This is a (callable) object, not a function. |
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
111–113 ↗ | (On Diff #253399) | Ah Sorry, I renamed them this way, to avoid confusion of naming while calling I'll change this as per Coding Standard. |
114–115 ↗ | (On Diff #253399) | 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 | ||
293 | Sorry, didn't get what you meant here ? |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
293 | Is naming not conforming to standard are you referring here parseAndDump ? |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
---|---|---|
293 | Right. Lambdas are objects, not functions, and so should follow the variable naming scheme, not the function naming scheme. |
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
111–113 ↗ | (On Diff #253399) | 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; |
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
293 | Thanks! done locally, we'll wait for @ikudrin before revising this. |
llvm/include/llvm/DebugInfo/DWARF/DWARFContext.h | ||
---|---|---|
288 ↗ | (On Diff #253399) |
|
llvm/lib/DebugInfo/DWARF/DWARFContext.cpp | ||
455–456 | This might be simplified to if (auto Macinfo = getDebugMacinfo()) Macinfo->dump(OS); | |
838–842 | The getters should look like const DWARFDebugMacro *DWARFContext::getDebugMacinfo() { if (!Macinfo) Macinfo = parseMacroOrMacinfo(MACINFO); return Macinfo.get(); } |
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.
I think it's OK - best I can tell at this point, given all the review iterations/comments/etc. *fingers crossed*
Missing trailing full stop.