Page MenuHomePhabricator

[ELF] - Partial support of --gdb-index command line option (Part 3).
ClosedPublic

Authored by grimar on Nov 3 2016, 9:04 AM.

Details

Summary

Patch continues work started in D24706 and D25821.

in this patch symbol table and constant pool areas were
added to .gdb_index section output.

Together with D25821 it should finish
the --gdb-index implementation in LLD.
(it is independent and can be committed/reviewed separatelly).

Diff Detail

Repository
rL LLVM

Event Timeline

grimar updated this revision to Diff 76868.Nov 3 2016, 9:04 AM
grimar retitled this revision from to [ELF] - Partial support of --gdb-index command line option (Part 3)..
grimar updated this object.
grimar added subscribers: davide, evgeny777, grimar, llvm-commits.
grimar updated this revision to Diff 80402.Dec 6 2016, 3:36 AM

Ping.

  • Rebased.
clayborg edited edge metadata.Dec 6 2016, 2:30 PM

Seems like the GdbIndex isn't specific to ELF. I know the file started off here and that some of the template classes you use are using ELF defines, but they don't really need to be in the ELF plug-in.

Would we want to move this functionality to the lib/DebugInfo/Dwarf/DWARFGdbIndex.cpp file so that other file formats like mach-o and COFF could create the gdb index section and be able to emit it? This code accesses existing DWARF sections and then creates the .gdb-index section contents.

ELF/GdbIndex.cpp
63 ↗(On Diff #80402)

Since we "do" not plan

ELF/SyntheticSections.cpp
1441 ↗(On Diff #80402)

use std::tie here with appropriate var names since you did it below?

1442 ↗(On Diff #80402)

I am guessing we can guarantee that the StringRef is NULL terminated here since the string probably originated from a string table.

1522 ↗(On Diff #80402)

use std::tie?

grimar added a comment.Dec 7 2016, 1:42 AM

Seems like the GdbIndex isn't specific to ELF. I know the file started off here and that some of the template classes you use are using ELF defines, but they don't really need to be in the ELF plug-in.

Would we want to move this functionality to the lib/DebugInfo/Dwarf/DWARFGdbIndex.cpp file so that other file formats like mach-o and COFF could create the gdb index section and be able to emit it? This code accesses existing DWARF sections and then creates the .gdb-index section contents.

If so I am not sure what is better ?

  1. Do that before landing this+D25821.
  2. Continue with landing above for ELF, complete and test functionality and then move it to lib/Debuginfo/Dwarf/* ?.

I would also create separate file for this like lib/DebugInfo/Dwarf/DWARFGdbIndexBuilder.cpp as DWARFGdbIndex.cpp is a parser and probably
better not to mix them.

Seems like the GdbIndex isn't specific to ELF. I know the file started off here and that some of the template classes you use are using ELF defines, but they don't really need to be in the ELF plug-in.

Would we want to move this functionality to the lib/DebugInfo/Dwarf/DWARFGdbIndex.cpp file so that other file formats like mach-o and COFF could create the gdb index section and be able to emit it? This code accesses existing DWARF sections and then creates the .gdb-index section contents.

If so I am not sure what is better ?

  1. Do that before landing this+D25821.
  2. Continue with landing above for ELF, complete and test functionality and then move it to lib/Debuginfo/Dwarf/* ?.

Not sure either. Probably fine to land it here with this change then migrate it.

I would also create separate file for this like lib/DebugInfo/Dwarf/DWARFGdbIndexBuilder.cpp as DWARFGdbIndex.cpp is a parser and probably
better not to mix them.

If it is the same stuff, I don't see a problem with the class being able to parse and generate the gdb index. You would probably share a lot of the same data structures and it would be a shame to duplicate those.

ELF/GdbIndex.cpp
100–101 ↗(On Diff #80402)

What happens if there is no pubnames or pubtypes? Do we want a separate path that actually manually goes through the DWARF and generates the correct info when these sections are missing?

Does the GDB index really live only on the pubnames and pubtypes? How useful is the GDB index if it doesn't include static functions and private types?

Ah, I missed the extra "gnu" in the pubnames and pubtypes. If these sections don't exist, can we generate them on the fly using common code and then use the generated data?

grimar added inline comments.Dec 8 2016, 5:22 AM
ELF/SyntheticSections.cpp
1441 ↗(On Diff #80402)

I am not sure what you mean, sorry. Do you meant next form ?

for (auto& p : someInitializingFunction()) {
  std::tie(a, b) = p;
  // do stuff;
}

If so I am probably missing for what.

1442 ↗(On Diff #80402)

Yes, and hash() relies on that. Do you want to change hash() signature ?

See inlined comments.

ELF/GdbIndex.cpp
105–118 ↗(On Diff #80402)

Might be worth putting this pubnames/pubtypes parser into the llvm/lib/DebugInfo/DWARF. We don't currently have a parser for this there. The more we duplicate code that is manually parsing DWARF sections outside of the DWARF parser the more fixes we need to make if the format gets updated.

ELF/SyntheticSections.cpp
1417 ↗(On Diff #80402)

Use StringRef here instead of "const char *"?

1420 ↗(On Diff #80402)

Use the StringRef iteration here?

1429 ↗(On Diff #80402)

Maybe add a:

if (Finalized)
  return;

So that this code works if asserts are not enabled? I would be great to reduce the amounts of places that use assert unconditionally in the llvm codebase.

1441 ↗(On Diff #80402)

Never mind, I was thinking you can use std::tie in the for loop:

for (std::tie(Name, Type) : NamesAndTypes) {

but you can't.

1442 ↗(On Diff #80402)

Might be safer to change the hash() signature if the only way we use it is with an llvm::StringRef.

1522 ↗(On Diff #80402)

Never mind, can't use std::tie in for loop

grimar updated this revision to Diff 80891.Dec 9 2016, 5:20 AM
grimar edited edge metadata.
  • Addressed review comments.
  • Make StringPool to be Kind of llvm::StringTableBuilder::ELF, that is correct I think and after that output for testcase is equal to gold.
ELF/GdbIndex.cpp
63 ↗(On Diff #80402)

Done.

105–118 ↗(On Diff #80402)

I wonder if that can be done in the following patch then ?
As far I understand that requires changing void dumpPubSection() from DebugInfo\DWARF\DWARFContext.cpp to something,
it should not be a big problem, I just suppose it is easier to do if we have at least one user of new functionality, so we can discuss the design of that change separatelly when see needs.
What do you think ? (I am ok to do take task of doing that change either before or after anyways, have no major preference here except that landing changes of this patch first makes things a bit easier to maintain).

ELF/SyntheticSections.cpp
1417 ↗(On Diff #80402)

Done.

1420 ↗(On Diff #80402)

Done.

1429 ↗(On Diff #80402)

I removed this assert. readDwarf() is now called only from parseDebugSections, which is already protected by

if (Finalized)
  return;
parseDebugSections();

So actually it was bit excessive assert. If for some reason this method will be called when Finalized, we should catch it in testcase anyways I think.

1442 ↗(On Diff #80402)

Done.

grimar updated this revision to Diff 80894.Dec 9 2016, 6:00 AM
  • Addressed comment not included by mistake in prev diff.

So it looks like it is down to wether we need to actually do the pubnames parsing stuff in lib/DebugInfo/DWARF or not. I'll let other make that call.

ELF/GdbIndex.cpp
118 ↗(On Diff #80894)

I'll let others comment on what is right to do as I am just starting out reviewing things in LLVM and don't know all the ropes. David?

dblaikie added inline comments.Dec 9 2016, 10:26 AM
ELF/GdbIndex.cpp
118 ↗(On Diff #80894)

Yeah, we go back and forth on stuff like this - in this case I think the code is short (granted, that also means the work to do it ahead of time isn't that big either) & George has been pretty responsive/quick on feedback/changes like this, so I'm OK with it going in after this patch.

I am good with the patch but I'll let others actually mark as accepted.

David, Greg, thanks !

Sorry, I am pinging this again because I am just not sure who is that person for approving this then ? I just see no objections from reviewers currently and looks all comments are addressed. I am also will be happy to prepare a discussed patch for LLVM parsers right after this one landed.
Landing this one + D25821 looks allows us to include gdb-index functionality into upcoming release planned early in 2017 afaik.

aprantl accepted this revision.Dec 14 2016, 8:58 AM
aprantl edited edge metadata.

I have a few more stylistic issues, but after fixing that, feel free to commit.

ELF/GdbIndex.cpp
157 ↗(On Diff #80894)

Coding guidelines want this to be a doxygen comment on the declaration in the header.
Is it possible to paraphrase the contents of the links in the comment? We don't usually put links into comments.

ELF/SyntheticSections.cpp
1416 ↗(On Diff #80894)

same here.

This revision is now accepted and ready to land.Dec 14 2016, 8:58 AM

Thank you for review Adrian !
I'll address all comments for this and D25821 with little general change:
we do not use Doxygen comments in tools/lld/ELF/* yet.

So I'll add regular ones for each place where it was requested. I am not sure why we do not use
Doxygen, but that moment already was discussed for these gdb_index patches before, so I hope it is still fine.

This revision was automatically updated to reflect the committed changes.

r289810

ELF/GdbIndex.cpp
157 ↗(On Diff #80894)

In LLD we often use the links in comments. Though in that case code itself just implements the formulas described in documentation. I replaced the link with short sentence about how it works in general.
And as I mentioned earlier, we do not use oxygen style comments in that lld folder yet, so that also was not changed.

ELF/SyntheticSections.cpp
1416 ↗(On Diff #80894)

I removed the link and added a short comment. We still have link in the file header, this comment refers to it.

Thank you for review Adrian !
I'll address all comments for this and D25821 with little general change:
we do not use Doxygen comments in tools/lld/ELF/* yet.

Now that's a really strange deviation from the LLVM coding guidelines! Why would we not want to use Doxygen comments there? Can someone explain the motivation behind this?

  • adrian