[lldb] Require x86 backend for a bunch of DWARF testsBy moving them into a folder with a local lit configrequiring x86. All these tests use x86 target triples.There are two tests that require ta
[lldb] Require x86 backend for a bunch of DWARF testsBy moving them into a folder with a local lit configrequiring x86. All these tests use x86 target triples.There are two tests that require target-x86_64 becausethey run program files (instead of just needing the backend).Those are moved to the x86 folder also but their REQUIRES areunchanged.Reviewed By: JDevlieghereDifferential Revision: https://reviews.llvm.org/D100193
show more ...
[lldb] Fix handling of `DW_AT_decl_file` according to D91014 (attempt #2)Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.Test case is pr
[lldb] Fix handling of `DW_AT_decl_file` according to D91014 (attempt #2)Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.Test case is provided by @jankratochvil.The test is marked to run only on x64 and exclude Windows and Darwin, because the assembly is not OS-independent.(First attempt https://reviews.llvm.org/D96778 broke the build bots)Reviewed By: jankratochvilDifferential Revision: https://reviews.llvm.org/D97765
Revert "[lldb] Fix handling of `DW_AT_decl_file` according to D91014"This reverts commit 7ec7876feda412b6edad0d83565395ef2fd5a004.Non-x86_64 non-Linux bots broke by the testcase.
[lldb] Fix handling of `DW_AT_decl_file` according to D91014Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.Differential Revision: https
[lldb] Fix handling of `DW_AT_decl_file` according to D91014Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.Differential Revision: https://reviews.llvm.org/D96778
lldb: Add support for printing variables with DW_AT_ranges on DW_TAG_subprogramsFinishing out the support (to the best of my knowledge/based on currenttesting running the whole check-lldb with a c
lldb: Add support for printing variables with DW_AT_ranges on DW_TAG_subprogramsFinishing out the support (to the best of my knowledge/based on currenttesting running the whole check-lldb with a clang forcibly usingDW_AT_ranges on all DW_TAG_subprograms) for this feature.Differential Revision: https://reviews.llvm.org/D94064
lldb: Add support for DW_AT_ranges on DW_TAG_subprogramsgcc already produces debug info with this form-freorder-block-and-partitionclang produces this sort of thing with -fbasic-block-sections an
lldb: Add support for DW_AT_ranges on DW_TAG_subprogramsgcc already produces debug info with this form-freorder-block-and-partitionclang produces this sort of thing with -fbasic-block-sections and with acoming-soon tweak to use ranges in DWARFv5 where they can allow greaterreuse of debug_addr than the low/high_pc forms.This fixes the case of breaking on a function name, but leaves brokenprinting a variable - a follow-up commit will add that and improve thetest case to match.Differential Revision: https://reviews.llvm.org/D94063
[ELF] Allow sections after a non-SHF_ALLOC section to be covered by PT_LOADGNU ld allows sections after a non-SHF_ALLOC section to be covered by PT_LOAD(PR37607) and assigns addresses to non-SHF_A
[ELF] Allow sections after a non-SHF_ALLOC section to be covered by PT_LOADGNU ld allows sections after a non-SHF_ALLOC section to be covered by PT_LOAD(PR37607) and assigns addresses to non-SHF_ALLOC output sections (similar toSHF_ALLOC NOBITS sections. The location counter is not advanced).This patch tries to fix PR37607 (remove a special case in`Writer<ELFT>::createPhdrs`). To make the created PT_LOAD meaningful, we cannotreset dot to 0 for a middle non-SHF_ALLOC output section. This results inremoval of two special cases in LinkerScript::assignOffsets. Non-SHF_ALLOCnon-orphan sections can have non-zero addresses like in GNU ld.The zero address rule for non-SHF_ALLOC sections is weakened to apply to orphanonly. This results in a special case in createSection and findOrphanPos, respectively.Reviewed By: jhendersonDifferential Revision: https://reviews.llvm.org/D85100
[lldb] Fix RecordDecl match string in module-ownership.mm to get the test running againThe relevant output FileCheck is scanning in this test is as follows: CXXRecordDecl 0x7f96cf8239c8 <<inva
[lldb] Fix RecordDecl match string in module-ownership.mm to get the test running againThe relevant output FileCheck is scanning in this test is as follows: CXXRecordDecl 0x7f96cf8239c8 <<invalid sloc>> <invalid sloc> imported in A.B <undeserialized declarations> struct definition <<DefinitionData boilerplate>> `-FieldDecl 0x7f96cf823b90 <<invalid sloc>> <invalid sloc> imported in A.B anon_field_b 'int' (anonymous struct) CXXRecordDecl 0x7f96cf823be8 <<invalid sloc>> <invalid sloc> imported in A.B structBefore 710fa2c4ee346e1ec2db66ac5fdf6909e79d9a8c this test was passing byaccident as it had a -DAG suffix in the checks changed by this patch,causing FileCheck to first match the last line of the output above(instead of the first one), and then finding the FieldDecl above.When I removed the -DAG suffix, FileCheck actually enforced the orderingand started failing as the FieldDecl comes before the CXXRecordDecl matchwe get.This patch fixes the CXXRecordDecl check to find the first line of the outputabove which caused FileCheck to also find the FieldDecl that follows. Alsogives the FieldDecl a more unique name to make name collisions less likely.
Allow lldb-test to combine -find with -dump-clang-astThis patch threads an lldb::DescriptionLevel through the typesystem toallow dumping the full Clang AST (level=verbose) of any lldb::Type inadd
Allow lldb-test to combine -find with -dump-clang-astThis patch threads an lldb::DescriptionLevel through the typesystem toallow dumping the full Clang AST (level=verbose) of any lldb::Type inaddition to the human-readable source description (defaultlevel=full). This type dumping interface is currently not exposedthrough the SBAPI.The application is to let lldb-test dump the clang AST of searchresults. I need this to test lazy type completion of clang types insubsequent patches.Differential Revision: https://reviews.llvm.org/D78329
Preserve the owning module information from DWARF in the synthesized ASTTypes that came from a Clang module are nested in DW_TAG_module tagsin DWARF. This patch recreates the Clang module hierarch
Preserve the owning module information from DWARF in the synthesized ASTTypes that came from a Clang module are nested in DW_TAG_module tagsin DWARF. This patch recreates the Clang module hierarchy in LLDB and1;95;0csets the owning module information accordingly. My primary motivationis to facilitate looking up per-module APINotes for individualdeclarations, but this likely also has other applications.This reapplies the previously reverted commit, but without support forClassTemplateSpecializations, which I'm going to look into separately.rdar://problem/59634380Differential Revision: https://reviews.llvm.org/D75488
Revert "Preserve the owning module information from DWARF in the synthesized AST"This reverts commit 4354dfbdf5c8510a7ddff10ae67a28e16cf7cc79 while investigating bot fallout.
Preserve the owning module information from DWARF in the synthesized ASTTypes that came from a Clang module are nested in DW_TAG_module tagsin DWARF. This patch recreates the Clang module hierarchy in LLDB andsets the owning module information accordingly. My primary motivationis to facilitate looking up per-module APINotes for individualdeclarations, but this likely also has other applications.rdar://problem/59634380Differential Revision: https://reviews.llvm.org/D75488
[lldb] Improve/fix base address selection in location listsSummary:Lldb support base address selection entries in location lists was brokenfor a long time. This wasn't noticed until llvm started
[lldb] Improve/fix base address selection in location listsSummary:Lldb support base address selection entries in location lists was brokenfor a long time. This wasn't noticed until llvm started producing thesekinds of entries more frequently with r374600.In r374769, I made a quick patch which added sufficient support for themto get the test suite to pass. However, I did not fully understand howthis code operates, and so the fix was not complete. Specifically, whatwas lacking was the ability to handle modules which were not loaded attheir preferred load address (for instance, due to ASLR).Now that I better understand how this code works, I've come to theconclusion that the current setup does not provide enough informationto correctly process these entries. In the current setup the locationlists were parameterized by two addresses:- the distance of the function start from the start of the compile unit. The purpose of this was to make the location ranges relative to the start of the function.- the actual address where the function was loaded at. With this the function-start-relative ranges can be translated to actual memory locations.The reason for the two values, instead of just one (the load bias) is (Ithink) MachO, where the debug info in the object files will appear to berelative to the address zero, but the actual code it refers tocan be moved and reordered by the linker. This means that the locationlists need to be "linked" to reflect the locations in the actual linkedfile.These two bits of information were enough to correctly process locationlists which do not contain base address selection entries (and so allentries are relative to the CU base). However, they don't work withthem because, in theory two base address can be completely unrelated (ascan happen for instace with hot/cold function splitting, where thelinker can reorder the two pars arbitrarily).To fix that, I split the first parameter into two:- the compile unit base address- the function start address, as is known in the object fileThe new algorithm becomes:- the location lists are processed as they were meant to be processed. The CU base address is used as the initial base address value. Base address selection entries can set a new base.- the difference between the "file" and "load" function start addresses is used to compute the load bias. This value is added to the final ranges to get the actual memory location.This algorithm is correct for non-MachO debug info, as there thelocation lists correctly describe the code in the final executable, andthe dynamic linker can just move the entire module, not pieces of it. Itwill also be correct for MachO if the static linker preserves relativepositions of the various parts of the location lists -- I don't knowwhether it actually does that, but judging by the lack of base addressselection support in dsymutil and lldb, this isn't something that hascome up in the past.I add a test case which simulates the ASLR scenario and demonstratesthat base address selection entries now work correctly here.Reviewers: JDevlieghere, aprantl, clayborgSubscribers: dblaikie, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D70532
Re-land "[test] Split LLDB tests into API, Shell & Unit"The original patch got reverted because it broke `check-lldb` on a cleanbuild. This fixes that.llvm-svn: 374201
Revert [test] Split LLDB tests into API, Shell & Unitas it appears to have broken check-lldb.This reverts r374184 (git commit 22314179f0660c172514b397060fd8f34b586e82)llvm-svn: 374187
[test] Split LLDB tests into API, Shell & UnitLLDB has three major testing strategies: unit tests, tests that exercisethe SB API though dotest.py and what we currently call lit tests. Thelater is
[test] Split LLDB tests into API, Shell & UnitLLDB has three major testing strategies: unit tests, tests that exercisethe SB API though dotest.py and what we currently call lit tests. Thelater is rather confusing as we're now using lit as the driver for allthree types of tests. As most of this grew organically, the directorystructure in the LLDB repository doesn't really make this clear.The 'lit' tests are part of the root and among these tests there's aUnit and Suite folder for the unit and dotest-tests. This layout makesit impossible to run just the lit tests.This patch changes the directory layout to match the 3 testingstrategies, each with their own directory and their own configurationfile. This means there are now 3 directories under lit with 3corresponding targets: - API (check-lldb-api): Test exercising the SB API. - Shell (check-lldb-shell): Test exercising command line utilities. - Unit (check-lldb-unit): Unit tests.Finally, there's still the `check-lldb` target that runs all three testsuites.Finally, this also renames the lit folder to `test` to match the LLVMrepository layout.Differential revision: https://reviews.llvm.org/D68606llvm-svn: 374184