bcm5719-llvm/lldb/source/Plugins/ObjectFile/PECOFF, branch meklort-10.0.1

[lldb] [PECOFF] Only use PECallFrameInfo on the one supported architecture

2020-05-19T01:24:44+00:00

The RuntimeFunction struct, which PECallFrameInfo interprets, has a different layout and differnet semantics on all architectures. Differential Revision: https://reviews.llvm.org/D77000 (cherry picked from commit aa786b881fc89a2a9883bff77912f2053126f95b)

[LLDB] [PECOFF] Make sure to set the address byte size in m_data after parsing headers

2019-12-10T11:55:38+00:00

If not set, the address byte size was implied to be the one of the host process. This allows reverting the functional change from 31087b2ae9154, since now PECOFF does the same as ELF and MachO wrt setting both byte order and address size on m_data within ParseHeader. Differential Revision: https://reviews.llvm.org/D71108

[lldb] Remove FileSpec(FileSpec*) constructor

2019-12-04T09:49:25+00:00

This constructor was the cause of some pretty weird behavior. Remove it, and update all code to properly dereference the argument instead.

[LLDB] [PECOFF] Look for the truncated ".eh_fram" section name

2019-11-28T09:27:00+00:00

COFF section names can either be stored truncated to 8 chars, in the section header, or as a longer section name, stored separately in the string table. libunwind locates the .eh_frame section by runtime introspection, which only works for section names stored in the section header (as the string table isn't mapped at runtime). To support this behaviour, lld always truncates the section names for sections that will be mapped, like .eh_frame. Differential Revision: https://reviews.llvm.org/D70745

[LLDB] [PECOFF] Factorize mapping section names to types using StringSwitch. NFCI.

2019-11-28T09:27:00+00:00

Keep the existing special cases based on combinations of section name, flags and sizes/offsets. Differential Revision: https://reviews.llvm.org/D70778

[LLDB] [PECOFF] Fix error handling for executables that object::createBinary errors out on

2019-10-31T09:26:21+00:00

llvm::object::createBinary returns an Expected<>, which requires not only checking the object for success, but also requires consuming the Error, if one was set. Use LLDB_LOG_ERROR for this case, and change an existing similar log statement to use it as well, to make sure the Error is consumed even if the log channel is disabled. Differential Revision: https://reviews.llvm.org/D69646

[LLDB] [PECOFF] Don't crash in ReadImageDataByRVA for addresses out of range

2019-10-31T09:26:06+00:00

This can happen e.g. when unwinding doesn't work perfectly. Differential Revision: https://reviews.llvm.org/D69502

COFF: Set section permissions

2019-10-30T13:13:21+00:00

Summary: This enables us to reason about whether a given address can be executable, for instance during unwinding. Reviewers: amccarth, mstorsjo Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D69102

[LLDB] [PECOFF] Use FindSectionByID to associate symbols to sections

2019-10-29T12:48:35+00:00

The virtual container/header section caused the section list to be offset by one, but by using FindSectionByID, the layout of the section list shouldn't matter. Differential Revision: https://reviews.llvm.org/D69366

lldb/COFF: Create a separate "section" for the file header

2019-10-25T22:11:53+00:00

In an attempt to ensure that every part of the module's memory image is accounted for, D56537 created a special "container section" spanning the entire image. While that seemed reasonable at the time (and it still mostly does), it did create a problem of what to put as the "file size" of the section, because the image is not continuous on disk, as we generally assume (which is why I put zero there). Additionally, this arrangement makes it unclear what kind of permissions should be assigned to that section (which is what my next patch does). To get around these, this patch partially reverts D56537, and goes back to top-level sections. Instead, what I do is create a new "section" for the object file header, which is also being loaded into memory, though its not considered to be a section in the strictest sense. This makes it possible to correctly assign file size section, and we can later assign permissions to it as well. Reviewers: amccarth, mstorsjo Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D69100