When creating LLDB types from `LF_MODIFIER` records, the type name of
the modified type was used. This didn't include the modifiers
(`const`/`volatile`/`__unaligned`). With this PR, they're included.
The DIA plugin had a test for this. That test also assumed that function
types had a name. I removed that check here, because function/procedure
types themselves in PDB don't have a name:
```
0x1015 | LF_ARGLIST [size = 20, hash = 0xBCB6]
0x0074 (int): `int`
0x1013: `int* __restrict`
0x1014: `int& __restrict`
0x1016 | LF_PROCEDURE [size = 16, hash = 0x3F611]
return type = 0x0003 (void), # args = 3, param list = 0x1015
calling conv = cdecl, options = None
```
I assume DIA gets the name from the function symbol itself. In the
native plugin, that name isn't included and multiple functions with the
same signature will reuse one type, whereas DIA would create a new type
for each function. The
[Shell/SymbolFile/PDB/func-symbols.test](https://github.com/llvm/llvm-project/blob/b29c7ded31d81ca47aed0157c543c8b6a0f5866c/lldb/test/Shell/SymbolFile/PDB/func-symbols.test)
also relies on this.
This PR implements `SymbolFileNativePDB::AddSymbols` which adds public symbols to the symbol table. These symbols are found in the publics stream. It contains mangled names coupled with addresses. Addresses are a pair of (segment, offset). If I understood correctly, then the segment is the section ID from the COFF header. Sections are already [constructed](https://github.com/llvm/llvm-project/blob/c48ec7fb60b5e0b4100731d75f82ea63c0ec7b45/lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp#L1048) using this 1-based index ([MS docs](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#section-table-section-headers)). This allows us to use `section_list->FindSectionByID`.
Lit allows you to set environment variables for all tests in a directory using a `lit.local.cfg` file. Do this for the PDB and NativePDB tests.
Fixes `lldb/test/Shell/SymbolFile/NativePDB/inline_sites.test` to use the correct line number now that https://github.com/llvm/llvm-project/commit/f2f36c9b2955d2d742a198416f1178fd80303921 is causing the inline call site info to be taken into account.
Differential Revision: https://reviews.llvm.org/D137287
If we don't add local variables with no location info, when trying to print it, lldb won't find it in the its parent DeclContext, which makes lldb to spend more time to search all the way up in DeclContext hierarchy until found same name variable or failed. Dwarf plugin also add local vars even if they don't have location info. Differential Revision: https://reviews.llvm.org/D133626
Before, NativePDB uses scoped range as a workaround for value range, that causes problems (e.g. a variable's value can only have one range, but usually a variable's value is located at different address ranges, each at different locations, in optimized build). This patch let NativePDB switch to DWARFLocationList so a variable's value can be described at multiple non-overlapped address ranges and each range maps to a location. Because overlapping ranges exists, here's peference when choosing ranges: 1. Always prefer whole value locations. Suppose a variable size is 8 bytes, one record is that for range [1, 5) first 4 bytes is at ecx, and another record is that for range [2, 8) the 8 bytes value is at rdx. This results: [1, 2) has first 4 bytes at ecx, [2, 8) has the whole value at rdx. 2. Always prefer the locations parsed later. Suppose first record is that for range [1, 5) value is at ecx, second record is that for range [2, 6) value is at eax. This results: [1, 2) -> ecx, [2, 6) -> eax. Differential Revision: https://reviews.llvm.org/D130796
It fixes the following case: ``` 0602 line 1 (+1) 0315 code 0x15 (+0x15) 0B2B code 0x20 (+0xB) line 2 (+1) 0602 line 3 (+1) 0311 code 0x31 (+0x11) ... ``` Inline ranges should have following mapping: `[0x15, 0x20) -> line 1` `[0x20, 0x31) -> line 2` Inline line entries: `0x15, line 1`, `0x20, line 2`, `0x31, line 3`. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D123092
This creates inline functions decls in the TUs where the funcitons are inlined and local variable decls inside those functions. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D121967