Allow using the object file name for debug symbol resolution

[sas]

Summary

In ObjectFileELF we try to read the .gnu_debuglink section of the ELF
file to determine the name of the debug symbols file. If this section
does not exist, we stop the search. Instead, what we should do is locate
a file with the same name as the ELF binary, which is the default
behavior when there isn't any .gnu_debuglink section present.

Ran check-lldb to make sure this doesn't break anything.

[davide]

I thought about this, and it's the only patch from your patchset that I don't feel really confident about.
I'm afraid it's a little risky to add more code to the objectfile reader without having proper unittesting.
In particular, we might want to either check in an object file (not so ideal) or use llvm-mc to produce a file with the correct section.
More generally, when we want to test debug info either we want to piggyback on mc or yaml2obj.
If none of them suffices, we should think about having a tool that takes a textual representation of some sort (YAML seems a good start) and produces a core dump to be passed to LLDB.
@sas what do you think?
cc:ing @vsk / @aprantl for thoughts.

[labath]

On 28 November 2017 at 06:12, Zachary Turner via lldb-commits <[e-mail]> wrote:

yaml2core would be an excellent idea for a tool.

An (elf) core file is an elf file, with metadata in the elf program headers, so I think this would naturally fit into yaml2obj. Unfortunately, yaml2obj currently does not support program headers (but there is a TODO to add that). If that TODO is fixed, we would have a yaml representation of both core files and elf executables (which we also can't do because they have program headers, and yaml2obj strips them).

The tricky part there is the specifying the interaction between program headers and section headers, as they describe overlapping views of the same data.

[aprantl]

yaml2obj sounds generally like a good solution. I should note that right now yaml2obj is only used/tested for the (narrow) use-case of testing the linker. For creating debug-info-related testcases, I found it both to high and too low an abstraction. Too low, because it currently forces you to manually specify details such as Mach-O load commands, and cannot calculate offsets itself (you really want some kind of label support), too high, because it can for example only synthesize DWARF4 headers in debug info sections. For this reason we often went with assembler instead of yaml for llvm-dwarfdump tests. None of the problems I mentioned should be unsurmountable, but the tool needs some love in order to make it useful for each specific use-case.

[clayborg]

I am not sure I follow this patch. We are adding a FileSpec whose path is just the basename of the current ELF file? What do we do with that? Do we look in certain directories to try and find this file? How this this basename added to the list end up getting found in the end?

[sas]

Basically, if you have a .debug directory in the same directory where the original object file is, you can have debug symbols there. For instance, you can have:

/my/project/myElf.exe
/my/project/.debug/myElf.exe

with the first file being a standard stripped elf file, and the second one being the associated debug symbols.

One other place where these names can be used is with the target.debug-file-search-paths setting.

[clayborg]

In D40539#937854, @sas wrote:

Basically, if you have a .debug directory in the same directory where the original object file is, you can have debug symbols there. For instance, you can have:

/my/project/myElf.exe
/my/project/.debug/myElf.exe

with the first file being a standard stripped elf file, and the second one being the associated debug symbols.

Do adding a FileSpec that contains just the basename will cause us to look for this file in the same directory as the original ELF file in the .debug folder? Does this occur elsewhere? Why not just construct the correct path in FileSpec to begin with?

[sas]

In D40539#937900, @clayborg wrote:

In D40539#937854, @sas wrote:

Basically, if you have a .debug directory in the same directory where the original object file is, you can have debug symbols there. For instance, you can have:

/my/project/myElf.exe
/my/project/.debug/myElf.exe

with the first file being a standard stripped elf file, and the second one being the associated debug symbols.

Do adding a FileSpec that contains just the basename will cause us to look for this file in the same directory as the original ELF file in the .debug folder?

Yes.

Does this occur elsewhere? Why not just construct the correct path in FileSpec to begin with?

It occurs in some other class where we try to locate the debug symbols for a given object file. There, we construct the list of paths to look for because we use multiple sources to get the paths. We use the setting I mentioned earlier, the .debug folder, and some order path scheme with .build-id folders.

[clayborg]

ok, this is fine then. Just need to test somehow.

source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

 }
 
 lldb_private::FileSpecList ObjectFileELF::GetDebugSymbolFilePaths() {
   FileSpecList file_spec_list;
 
   if (!m_gnu_debuglink_file.empty()) {
     FileSpec file_spec(m_gnu_debuglink_file, false);
     file_spec_list.Append(file_spec);
+  } else {
+    FileSpec file_spec(GetFileSpec().GetFilename().AsCString(), false);
+    file_spec_list.Append(file_spec);
   }
+
   return file_spec_list;
 }
 
 uint32_t ObjectFileELF::GetDependentModules(FileSpecList &files) {
   size_t num_modules = ParseDependentModules();
   uint32_t num_specs = 0;
 
   for (unsigned i = 0; i < num_modules; ++i) {