This is an archive of the discontinued LLVM Phabricator instance.

minidump: Add ability to attach (breakpad) symbol files to placeholder modules
ClosedPublic

Authored by labath on Feb 5 2019, 7:07 AM.

Details

Summary

The reason this wasn't working was that ProcessMinidump was creating odd
object-file-less modules, and SymbolFileBreakpad required the module to
have an associated object file because it needed to get its base
address.

This fixes that by introducing a PlaceholderObjectFile to serve as a
dummy object file. The general idea for this is taken from D55142, but
I've reworked it a bit to avoid the need for the PlaceholderModule
class. Now that we have an object file, our modules are sufficiently
similar to regular modules that we can use the regular Module class
almost out of the box -- the only thing I needed to tweak was the
Module::CreateModuleFromObjectFile functon to set the module's FileSpec
in addition to it's architecture. This wasn't needed for ObjectFileJIT
(the other user of CreateModuleFromObjectFile), but it shouldn't hurt it
either, and the change seems like a straightforward extension of this
function.

Diff Detail

Repository
rLLDB LLDB

Event Timeline

labath created this revision.Feb 5 2019, 7:07 AM
amccarth accepted this revision.Feb 5 2019, 11:08 AM

Nice.

This revision is now accepted and ready to land.Feb 5 2019, 11:08 AM

Check the comment about m_platform_file

include/lldb/Core/Module.h
174–175

Why do we need to update the m_file? m_platform_file is the path of the module as it is known the the remote system, so if m_file differs from the object file's file spec, we might want to shuffle, m_file into m_platform_file first and then overwrite it?

lemo accepted this revision.Feb 5 2019, 12:20 PM

Looks good - a few comments inline.

include/lldb/Core/Module.h
176

nit: return std::move(x) is almost never a good idea. It's not needed, verbose and most importantly it actually inhibits NRVO so it's likely less efficient.

source/Plugins/Process/minidump/ProcessMinidump.cpp
51–83

Can we avoid passing both the module_sp and module_spec? I try to avoid interfaces which allow for inconsistent states, ex: what if module_sp and module_spec describe completely different modules?

At very least I'd add a few asserts, but if we can change the interface to avoid it, even better.

52

Nice - so we can do without this in all scenarios? What about PDBs?

66

should we dump something meaningful? I don't remember the exact command but I think this surfaces in user output

labath updated this revision to Diff 185513.Feb 6 2019, 2:30 AM
labath marked 8 inline comments as done.
  • remove std::move
  • avoid using the word "update" in CreateModuleFromObjectFile
  • implement the Dump method and cover it with a test
include/lldb/Core/Module.h
174–175

I used the word "update", because the previous comment did, but this isn't really "updating" anything. It is just "setting" the FileSpec because it was previously empty (the module we're setting this on is created a couple of lines back (line 163) as an empty module. The entire reason for existence of this function is to perform the articulate dance of creating the objects in the right order (because ObjectFile stores a shared_ptr to the module, it needs to be created after the ModuleSP is fully constructed).

So, there isn't to shuffle here. We just set m_file, to whatever the ObjectFile tells us is the file it was created from.

176

Yep, I should have known that. I'll remove it.

source/Plugins/Process/minidump/ProcessMinidump.cpp
51–83

Yeah, I agree this interface is weird, but this is kind of necessary to make the CreateModuleFromObjectFile flow work. The idea there is to create an empty module, then place an ObjectFile inside of it, and then use the data from the ObjectFile to initialize the module.

So, at the point when this function is called, the module_sp object will be empty (so there isn't anything to assert). It's only present here to satisfy the ObjectFile contract and set up the weak_ptr backlink. The module_spec contains the actual data, which is used to initialize the PlaceholderObjectFile (and which will then in turn initialize the Module object).

52

I haven't tried anything special besides running existing tests, but I don't think this should hamper anything. The modules I create here will be fairly realistic, they will have UUIDs, ObjectFiles and everything. So if the PDBs were able to attach to the PlaceholderModules, they should certainly be able to do the same with regular modules + PlaceholderObjectFiles.

66

I guess you meant "image dump objfile". It's kind of weird because that command prefixes the output with "outputting headers for <N> modules", and I have no idea what would be the "headers" for this object file. However I suppose a short one line summary of the file is better than just printing nothing.

labath added a comment.Feb 8 2019, 3:57 AM

Hi Greg, what do you think of my replies to your CreateModuleFromObjectFile comment?

clayborg accepted this revision.Feb 8 2019, 10:18 AM

Hi Greg, what do you think of my replies to your CreateModuleFromObjectFile comment?

Your explanation makes sense. I missed the fact that this function was creating a module from an object file!

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 11 2019, 1:31 AM
Herald added a subscriber: abidh. · View Herald Transcript