maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/unittests/ObjectFile/ELF/TestObjectFileELF.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

279 lines
9.6 KiB
C++
Raw Normal View History

[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
//===-- TestObjectFileELF.cpp ---------------------------------------------===//
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
//
//===----------------------------------------------------------------------===//
#include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
SymbolVendor: Move Symtab construction into the SymbolFile Summary: Instead of having SymbolVendor coordinate Symtab construction between Symbol and Object files, make the SymbolVendor function a passthrough, and put all of the logic into the SymbolFile. Reviewers: clayborg, JDevlieghere, jingham, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65208 llvm-svn: 367086
2019-07-26 15:03:28 +08:00
#include "Plugins/SymbolFile/Symtab/SymbolFileSymtab.h"
[lldb] Add a SubsystemRAII that takes care of calling Initialize and Terminate in the unit tests Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code. This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls. Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower. Reviewers: labath, JDevlieghere, martong, espindola, shafik Reviewed By: labath Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71630
2019-12-23 17:38:12 +08:00
#include "TestingSupport/SubsystemRAII.h"
ObjectFileELF: Add support for compressed sections Summary: We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables us to read data from debug info sections, which are sometimes compressed, particuarly in the split-dwarf case. This functionality is only available if llvm is compiled with zlib support. Reviewers: clayborg, zturner Subscribers: emaste, mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D40616 llvm-svn: 320813
2017-12-15 22:23:58 +08:00
#include "TestingSupport/TestUtilities.h"
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
#include "lldb/Core/Module.h"
#include "lldb/Core/ModuleSpec.h"
#include "lldb/Core/Section.h"
[FileSystem] Extend file system and have it use the VFS. This patch extends the FileSystem class with a bunch of functions that are currently implemented as methods of the FileSpec class. These methods will be removed in future commits and replaced by calls to the file system. The new functions are operated in terms of the virtual file system which was recently moved from clang into LLVM so it could be reused in lldb. Because the VFS is stateful, we turned the FileSystem class into a singleton. Differential revision: https://reviews.llvm.org/D53532 llvm-svn: 345783
2018-11-01 05:49:27 +08:00
#include "lldb/Host/FileSystem.h"
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
#include "lldb/Host/HostInfo.h"
Add a relocation to ObjectFileELF::ApplyRelocations and a test Summary: pcm files can end up being processed by lldb with relocations to be made for the .debug_info section. When a R_AARCH64_ABS64 relocation was required lldb would hit an `assert(false)` and die. Add R_AARCH64_ABS64 relocations to the S+A 64 bit width code path. Add a test for R_AARCH64_ABS64 and R_AARCH64_ABS32 .rela.debug_info relocations in a pcm file. Reviewers: sas, xiaobai, davide, javed.absar, espindola Reviewed By: davide Subscribers: labath, zturner, emaste, mgorny, arichardson, kristof.beyls Differential Revision: https://reviews.llvm.org/D51566 llvm-svn: 346171
2018-11-06 06:18:00 +08:00
#include "lldb/Utility/DataBufferHeap.h"
[unittests] Speculative fix for changes introduced in rL313156 llvm-svn: 313181
2017-09-14 04:02:24 +08:00
#include "llvm/ADT/Optional.h"
ObjectFileELF: Add support for compressed sections Summary: We use the llvm decompressor to decompress SHF_COMPRESSED sections. This enables us to read data from debug info sections, which are sometimes compressed, particuarly in the split-dwarf case. This functionality is only available if llvm is compiled with zlib support. Reviewers: clayborg, zturner Subscribers: emaste, mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D40616 llvm-svn: 320813
2017-12-15 22:23:58 +08:00
#include "llvm/Support/Compression.h"
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
#include "llvm/Support/FileUtilities.h"
#include "llvm/Support/Path.h"
#include "llvm/Support/Program.h"
#include "llvm/Support/raw_ostream.h"
Include inlined functions when figuring out a contiguous address range Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
2019-05-07 04:01:21 +08:00
#include "llvm/Testing/Support/Error.h"
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
#include "gtest/gtest.h"
using namespace lldb_private;
using namespace lldb;
class ObjectFileELFTest : public testing::Test {
[lldb] Add a SubsystemRAII that takes care of calling Initialize and Terminate in the unit tests Summary: Many of our tests need to initialize certain subsystems/plugins of LLDB such as `FileSystem` or `HostInfo` by calling their static `Initialize` functions before the test starts and then calling `::Terminate` after the test is done (in reverse order). This adds a lot of error-prone boilerplate code to our testing code. This patch adds a RAII called SubsystemRAII that ensures that we always call ::Initialize and then call ::Terminate after the test is done (and that the Terminate calls are always in the reverse order of the ::Initialize calls). It also gets rid of all of the boilerplate that we had for these calls. Per-fixture initialization is still not very nice with this approach as it would require some kind of static unique_ptr that gets manually assigned/reseted from the gtest SetUpTestCase/TearDownTestCase functions. Because of that I changed all per-fixture setup to now do per-test setup which can be done by just having the SubsystemRAII as a member of the test fixture. This change doesn't influence our normal test runtime as LIT anyway runs each test case separately (and the Initialize/Terminate calls are anyway not very expensive). It will however make running all tests in a single executable slightly slower. Reviewers: labath, JDevlieghere, martong, espindola, shafik Reviewed By: labath Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71630
2019-12-23 17:38:12 +08:00
SubsystemRAII<FileSystem, HostInfo, ObjectFileELF, SymbolFileSymtab>
subsystems;
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
};
TEST_F(ObjectFileELFTest, SectionsResolveConsistently) {
unittests: Use yaml2obj as a library instead of an external process Summary: Recently, yaml2obj has been turned into a library. This means we can use it from our unit tests directly, instead of shelling out to an external process. This patch does just that. Reviewers: JDevlieghere, aadsm, espindola, jdoerfert Subscribers: emaste, mgorny, arichardson, MaskRay, jhenderson, abrachet, lldb-commits Differential Revision: https://reviews.llvm.org/D65949 llvm-svn: 369374
2019-08-20 20:28:36 +08:00
auto ExpectedFile = TestFile::fromYaml(R"(
--- !ELF
FileHeader:
Class: ELFCLASS64
Data: ELFDATA2LSB
Type: ET_EXEC
Machine: EM_X86_64
Entry: 0x0000000000400180
Sections:
- Name: .note.gnu.build-id
Type: SHT_NOTE
Flags: [ SHF_ALLOC ]
Address: 0x0000000000400158
AddressAlign: 0x0000000000000004
Content: 040000001400000003000000474E55003F3EC29E3FD83E49D18C4D49CD8A730CC13117B6
- Name: .text
Type: SHT_PROGBITS
Flags: [ SHF_ALLOC, SHF_EXECINSTR ]
Address: 0x0000000000400180
AddressAlign: 0x0000000000000010
Content: 554889E58B042500106000890425041060005DC3
- Name: .data
Type: SHT_PROGBITS
Flags: [ SHF_WRITE, SHF_ALLOC ]
Address: 0x0000000000601000
AddressAlign: 0x0000000000000004
Content: 2F000000
- Name: .bss
Type: SHT_NOBITS
Flags: [ SHF_WRITE, SHF_ALLOC ]
Address: 0x0000000000601004
AddressAlign: 0x0000000000000004
Size: 0x0000000000000004
Symbols:
- Name: Y
Type: STT_OBJECT
Section: .data
Value: 0x0000000000601000
Size: 0x0000000000000004
Binding: STB_GLOBAL
- Name: _start
Type: STT_FUNC
Section: .text
Value: 0x0000000000400180
Size: 0x0000000000000014
Binding: STB_GLOBAL
- Name: X
Type: STT_OBJECT
Section: .bss
Value: 0x0000000000601004
Size: 0x0000000000000004
Binding: STB_GLOBAL
...
)");
ASSERT_THAT_EXPECTED(ExpectedFile, llvm::Succeeded());
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
[lldb/Module] Allow for the creation of memory-only modules Summary: This patch extends the ModuleSpec class to include a DataBufferSP which contains the module data. If this data is provided, LLDB won't try to hit the filesystem to create the Module, but use only the data stored in the ModuleSpec. Reviewers: labath, espindola Subscribers: emaste, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D83512
2020-07-10 05:14:36 +08:00
auto module_sp = std::make_shared<Module>(ExpectedFile->moduleSpec());
ObjectFileELF: Fix symbol lookup in bss section Summary: If we have symbol information in a separate file, we need to be very careful about presenting a unified section view of module to the rest of the debugger. ObjectFileELF had code to handle that, but it was being overly cautious -- the section->GetFileSize()!=0 meant that the unification would fail for sections which do not occupy any space in the object file (e.g., .bss). In my case, that manifested itself as not being able to display the values of .bss variables properly as the section associated with the variable did not have it's load address set (because it was not present in the unified section list). I test this by making sure the unified section list and the variables refer to the same section. Reviewers: eugene, zturner Subscribers: tberghammer, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D32434 llvm-svn: 301917
2017-05-02 20:40:31 +08:00
SectionList *list = module_sp->GetSectionList();
ASSERT_NE(nullptr, list);
auto bss_sp = list->FindSectionByName(ConstString(".bss"));
ASSERT_NE(nullptr, bss_sp);
auto data_sp = list->FindSectionByName(ConstString(".data"));
ASSERT_NE(nullptr, data_sp);
auto text_sp = list->FindSectionByName(ConstString(".text"));
ASSERT_NE(nullptr, text_sp);
const Symbol *X = module_sp->FindFirstSymbolWithNameAndType(ConstString("X"),
eSymbolTypeAny);
ASSERT_NE(nullptr, X);
EXPECT_EQ(bss_sp, X->GetAddress().GetSection());
const Symbol *Y = module_sp->FindFirstSymbolWithNameAndType(ConstString("Y"),
eSymbolTypeAny);
ASSERT_NE(nullptr, Y);
EXPECT_EQ(data_sp, Y->GetAddress().GetSection());
const Symbol *start = module_sp->FindFirstSymbolWithNameAndType(
ConstString("_start"), eSymbolTypeAny);
ASSERT_NE(nullptr, start);
EXPECT_EQ(text_sp, start->GetAddress().GetSection());
}
Fix parsing of object files with "early" section headers ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code which was trying to avoid loading the full object file into memory. It did this by trying to load data only up to the offset if was accessing. However, in practice this was useless, as 99% of object files we encounter have section headers at the end, so we would load the whole file as soon as we start parsing the section headers. In fact, this would break as soon as we encounter a file which does *not* have section headers at the end (yaml2obj produces these), as the access to .strtab (which we need to get the section names) was not guarded by this offset check. As this strategy was completely ineffective anyway, I do not attempt to proliferate it further by guarding the .strtab accesses. Instead I just lead the full file as soon as we are reasonably sure that we are indeed processing an elf file. If we really care about the load size here, we would need to reimplement this to just load the bits of the object file we need, instead of loading everything from the start of the object file to the given offset. However, given that the OS will do this for us for free when using mmap, I think think this is really necessary. For testing this I check a (tiny) SO file instead of yaml2obj-ing it because the fact that they come out first is an implementation detail of yaml2obj that can change in the future. llvm-svn: 324254
2018-02-06 01:25:40 +08:00
// Test that GetModuleSpecifications works on an "atypical" object file which
// has section headers right after the ELF header (instead of the more common
// layout where the section headers are at the very end of the object file).
Add a comment explaining how the input for GetModuleSpecifications_EarlySectionHeaders was generated Davide pointed out this would be useful if the file ever needs to be regenerated (and I certainly agree). I also replace the test binary with a slightly smaller one -- I intended to do this in the original commit, but I forgot to add it to the patch as I was juggling several things at the same time. llvm-svn: 324256
2018-02-06 02:03:02 +08:00
//
// Test file generated with yaml2obj (@svn rev 324254) from the following input:
/*
--- !ELF
FileHeader:
Class: ELFCLASS64
Data: ELFDATA2LSB
Type: ET_EXEC
Machine: EM_X86_64
Entry: 0x00000000004003D0
Sections:
- Name: .note.gnu.build-id
Type: SHT_NOTE
Flags: [ SHF_ALLOC ]
Address: 0x0000000000400274
AddressAlign: 0x0000000000000004
Content: 040000001400000003000000474E55001B8A73AC238390E32A7FF4AC8EBE4D6A41ECF5C9
- Name: .text
Type: SHT_PROGBITS
Flags: [ SHF_ALLOC, SHF_EXECINSTR ]
Address: 0x00000000004003D0
AddressAlign: 0x0000000000000010
Content: DEADBEEFBAADF00D
...
*/
Fix parsing of object files with "early" section headers ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code which was trying to avoid loading the full object file into memory. It did this by trying to load data only up to the offset if was accessing. However, in practice this was useless, as 99% of object files we encounter have section headers at the end, so we would load the whole file as soon as we start parsing the section headers. In fact, this would break as soon as we encounter a file which does *not* have section headers at the end (yaml2obj produces these), as the access to .strtab (which we need to get the section names) was not guarded by this offset check. As this strategy was completely ineffective anyway, I do not attempt to proliferate it further by guarding the .strtab accesses. Instead I just lead the full file as soon as we are reasonably sure that we are indeed processing an elf file. If we really care about the load size here, we would need to reimplement this to just load the bits of the object file we need, instead of loading everything from the start of the object file to the given offset. However, given that the OS will do this for us for free when using mmap, I think think this is really necessary. For testing this I check a (tiny) SO file instead of yaml2obj-ing it because the fact that they come out first is an implementation detail of yaml2obj that can change in the future. llvm-svn: 324254
2018-02-06 01:25:40 +08:00
TEST_F(ObjectFileELFTest, GetModuleSpecifications_EarlySectionHeaders) {
std::string SO = GetInputFilePath("early-section-headers.so");
ModuleSpecList Specs;
[FileSystem] Move path resolution logic out of FileSpec This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
2018-11-02 05:05:36 +08:00
ASSERT_EQ(1u, ObjectFile::GetModuleSpecifications(FileSpec(SO), 0, 0, Specs));
Fix parsing of object files with "early" section headers ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code which was trying to avoid loading the full object file into memory. It did this by trying to load data only up to the offset if was accessing. However, in practice this was useless, as 99% of object files we encounter have section headers at the end, so we would load the whole file as soon as we start parsing the section headers. In fact, this would break as soon as we encounter a file which does *not* have section headers at the end (yaml2obj produces these), as the access to .strtab (which we need to get the section names) was not guarded by this offset check. As this strategy was completely ineffective anyway, I do not attempt to proliferate it further by guarding the .strtab accesses. Instead I just lead the full file as soon as we are reasonably sure that we are indeed processing an elf file. If we really care about the load size here, we would need to reimplement this to just load the bits of the object file we need, instead of loading everything from the start of the object file to the given offset. However, given that the OS will do this for us for free when using mmap, I think think this is really necessary. For testing this I check a (tiny) SO file instead of yaml2obj-ing it because the fact that they come out first is an implementation detail of yaml2obj that can change in the future. llvm-svn: 324254
2018-02-06 01:25:40 +08:00
ModuleSpec Spec;
ASSERT_TRUE(Specs.GetModuleSpecAtIndex(0, Spec)) ;
UUID Uuid;
Support build-ids of other sizes than 16 in UUID::SetFromStringRef SBTarget::AddModule currently handles the UUID parameter in a very weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On the other hand, shorter-than-16-bytes UUIDs are completely ignored. In this patch, we change the parsing code to handle UUIDs of arbitrary size. To support arbitrary size UUIDs in SBTarget::AddModule, this patch changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We subtly change the semantics of SetFromStringRef - SetFromStringRef now only succeeds if the entire input is consumed to prevent some prefix-parsing confusion. This is up for discussion, but I believe this is more consistent - we always return false for invalid UUIDs rather than sometimes truncating to a valid prefix. Also, all the call-sites except the API and interpreter seem to expect to consume the entire input. This also adds tests for adding existing modules 4-, 16-, and 20-byte build-ids. Finally, we took the liberty of testing the minidump scenario we care about - removing placeholder module from minidump and replacing it with the real module. Reviewed By: labath, friss Differential Revision: https://reviews.llvm.org/D80755
2020-06-02 04:43:18 +08:00
Uuid.SetFromStringRef("1b8a73ac238390e32a7ff4ac8ebe4d6a41ecf5c9");
Fix parsing of object files with "early" section headers ObjectFileELF::GetModuleSpecifications contained a lot of tip-toing code which was trying to avoid loading the full object file into memory. It did this by trying to load data only up to the offset if was accessing. However, in practice this was useless, as 99% of object files we encounter have section headers at the end, so we would load the whole file as soon as we start parsing the section headers. In fact, this would break as soon as we encounter a file which does *not* have section headers at the end (yaml2obj produces these), as the access to .strtab (which we need to get the section names) was not guarded by this offset check. As this strategy was completely ineffective anyway, I do not attempt to proliferate it further by guarding the .strtab accesses. Instead I just lead the full file as soon as we are reasonably sure that we are indeed processing an elf file. If we really care about the load size here, we would need to reimplement this to just load the bits of the object file we need, instead of loading everything from the start of the object file to the given offset. However, given that the OS will do this for us for free when using mmap, I think think this is really necessary. For testing this I check a (tiny) SO file instead of yaml2obj-ing it because the fact that they come out first is an implementation detail of yaml2obj that can change in the future. llvm-svn: 324254
2018-02-06 01:25:40 +08:00
EXPECT_EQ(Spec.GetUUID(), Uuid);
}
Explicitly set entry point arch when it's thumb [Second Try] Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
2019-10-09 07:44:49 +08:00
TEST_F(ObjectFileELFTest, GetSymtab_NoSymEntryPointArmThumbAddressClass) {
/*
// nosym-entrypoint-arm-thumb.s
.thumb_func
_start:
mov r0, #42
mov r7, #1
svc #0
// arm-linux-androideabi-as nosym-entrypoint-arm-thumb.s
// -o nosym-entrypoint-arm-thumb.o
// arm-linux-androideabi-ld nosym-entrypoint-arm-thumb.o
// -o nosym-entrypoint-arm-thumb -e 0x8075 -s
*/
auto ExpectedFile = TestFile::fromYaml(R"(
--- !ELF
FileHeader:
Class: ELFCLASS32
Data: ELFDATA2LSB
Type: ET_EXEC
Machine: EM_ARM
Flags: [ EF_ARM_SOFT_FLOAT, EF_ARM_EABI_VER5 ]
Entry: 0x0000000000008075
Sections:
- Name: .text
Type: SHT_PROGBITS
Flags: [ SHF_ALLOC, SHF_EXECINSTR ]
Address: 0x0000000000008074
AddressAlign: 0x0000000000000002
Content: 2A20012700DF
- Name: .data
Type: SHT_PROGBITS
Flags: [ SHF_WRITE, SHF_ALLOC ]
Address: 0x0000000000009000
AddressAlign: 0x0000000000000001
Content: ''
- Name: .bss
Type: SHT_NOBITS
Flags: [ SHF_WRITE, SHF_ALLOC ]
Address: 0x0000000000009000
AddressAlign: 0x0000000000000001
- Name: .note.gnu.gold-version
Type: SHT_NOTE
AddressAlign: 0x0000000000000004
Content: 040000000900000004000000474E5500676F6C6420312E3131000000
- Name: .ARM.attributes
Type: SHT_ARM_ATTRIBUTES
AddressAlign: 0x0000000000000001
Content: '4113000000616561626900010900000006020901'
...
)");
ASSERT_THAT_EXPECTED(ExpectedFile, llvm::Succeeded());
[lldb/Module] Allow for the creation of memory-only modules Summary: This patch extends the ModuleSpec class to include a DataBufferSP which contains the module data. If this data is provided, LLDB won't try to hit the filesystem to create the Module, but use only the data stored in the ModuleSpec. Reviewers: labath, espindola Subscribers: emaste, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D83512
2020-07-10 05:14:36 +08:00
auto module_sp = std::make_shared<Module>(ExpectedFile->moduleSpec());
Explicitly set entry point arch when it's thumb [Second Try] Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
2019-10-09 07:44:49 +08:00
auto entry_point_addr = module_sp->GetObjectFile()->GetEntryPointAddress();
ASSERT_TRUE(entry_point_addr.GetOffset() & 1);
// Decrease the offsite by 1 to make it into a breakable address since this
// is Thumb.
entry_point_addr.SetOffset(entry_point_addr.GetOffset() - 1);
ASSERT_EQ(entry_point_addr.GetAddressClass(),
AddressClass::eCodeAlternateISA);
}
TEST_F(ObjectFileELFTest, GetSymtab_NoSymEntryPointArmAddressClass) {
/*
// nosym-entrypoint-arm.s
_start:
movs r0, #42
movs r7, #1
svc #0
// arm-linux-androideabi-as nosym-entrypoint-arm.s
// -o nosym-entrypoint-arm.o
// arm-linux-androideabi-ld nosym-entrypoint-arm.o
// -o nosym-entrypoint-arm -e 0x8074 -s
*/
auto ExpectedFile = TestFile::fromYaml(R"(
--- !ELF
FileHeader:
Class: ELFCLASS32
Data: ELFDATA2LSB
Type: ET_EXEC
Machine: EM_ARM
Flags: [ EF_ARM_SOFT_FLOAT, EF_ARM_EABI_VER5 ]
Entry: 0x0000000000008074
Sections:
- Name: .text
Type: SHT_PROGBITS
Flags: [ SHF_ALLOC, SHF_EXECINSTR ]
Address: 0x0000000000008074
AddressAlign: 0x0000000000000004
Content: 2A00A0E30170A0E3000000EF
- Name: .data
Type: SHT_PROGBITS
Flags: [ SHF_WRITE, SHF_ALLOC ]
Address: 0x0000000000009000
AddressAlign: 0x0000000000000001
Content: ''
- Name: .bss
Type: SHT_NOBITS
Flags: [ SHF_WRITE, SHF_ALLOC ]
Address: 0x0000000000009000
AddressAlign: 0x0000000000000001
- Name: .note.gnu.gold-version
Type: SHT_NOTE
AddressAlign: 0x0000000000000004
Content: 040000000900000004000000474E5500676F6C6420312E3131000000
- Name: .ARM.attributes
Type: SHT_ARM_ATTRIBUTES
AddressAlign: 0x0000000000000001
Content: '4113000000616561626900010900000006010801'
...
)");
ASSERT_THAT_EXPECTED(ExpectedFile, llvm::Succeeded());
[lldb/Module] Allow for the creation of memory-only modules Summary: This patch extends the ModuleSpec class to include a DataBufferSP which contains the module data. If this data is provided, LLDB won't try to hit the filesystem to create the Module, but use only the data stored in the ModuleSpec. Reviewers: labath, espindola Subscribers: emaste, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D83512
2020-07-10 05:14:36 +08:00
auto module_sp = std::make_shared<Module>(ExpectedFile->moduleSpec());
Explicitly set entry point arch when it's thumb [Second Try] Summary: This is a redo of D68069 because I reverted it due to some concerns that were now addressed along with the new comments that @labath added. I found a case where the main android binary (app_process32) had thumb code at its entry point but no entry in the symbol table indicating this. This made lldb set a 4 byte breakpoint at that address (we default to arm code) instead of a 2 byte one (like we should for thumb). The big deal with this is that the expression evaluator uses the entry point as a way to know when a JITed expression has finished executing by putting a breakpoint there. Because of this, evaluating expressions on certain android devices (Google Pixel something) made the process crash. This was fixed by checking this specific situation when we parse the symbol table and add an artificial symbol for this 2 byte range and indicating that it's arm thumb. I created 2 unit tests for this, one to check that now we know that the entry point is arm thumb, and the other to make sure we didn't change the behaviour for arm code. I also run the following on the command line with the `app_process32` where I found the issue: **Before:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32[0x1640]: .long 0xf0004668 ; unknown opcode ``` **After:** ``` (lldb) dis -s 0x1640 -e 0x1644 app_process32`: app_process32[0x1640] <+0>: mov r0, sp app_process32[0x1642]: andeq r0, r0, r0 ``` Reviewers: clayborg, labath, wallace, espindola Reviewed By: labath Subscribers: labath, lldb-commits, MaskRay, kristof.beyls, arichardson, emaste, srhines Tags: #lldb Differential Revision: https://reviews.llvm.org/D68533 llvm-svn: 374132
2019-10-09 07:44:49 +08:00
auto entry_point_addr = module_sp->GetObjectFile()->GetEntryPointAddress();
ASSERT_EQ(entry_point_addr.GetAddressClass(), AddressClass::eCode);
Support build-ids of other sizes than 16 in UUID::SetFromStringRef SBTarget::AddModule currently handles the UUID parameter in a very weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On the other hand, shorter-than-16-bytes UUIDs are completely ignored. In this patch, we change the parsing code to handle UUIDs of arbitrary size. To support arbitrary size UUIDs in SBTarget::AddModule, this patch changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We subtly change the semantics of SetFromStringRef - SetFromStringRef now only succeeds if the entire input is consumed to prevent some prefix-parsing confusion. This is up for discussion, but I believe this is more consistent - we always return false for invalid UUIDs rather than sometimes truncating to a valid prefix. Also, all the call-sites except the API and interpreter seem to expect to consume the entire input. This also adds tests for adding existing modules 4-, 16-, and 20-byte build-ids. Finally, we took the liberty of testing the minidump scenario we care about - removing placeholder module from minidump and replacing it with the real module. Reviewed By: labath, friss Differential Revision: https://reviews.llvm.org/D80755
2020-06-02 04:43:18 +08:00
}