This moves all the generic MCP code into the new ProtocolMCP library so
it can be shared between the MCP implementation in LLDB (built on the
private API) and lldb-mcp (built on the public API).
This PR doesn't include the actual MCP server. The reason is that the
transport mechanism will be different between the LLDB implementation
(using sockets) and the lldb-mcp implementation (using stdio). The goal
s to abstract away that difference by making the server use
JSONTransport (again) but I'm saving that for a separate PR.
Module files shouldn't ever produce parsing errors, and if they did in
the case of a badly-generated module file, the compiler will notice and
crash. So we can run the parser on module files with message deferral
enabled, and that saves time that would otherwise be spent generating
messages on failed parsing alternatives that are discarded anyway when
backtracking. It's not a big savings (single digit percentage on overall
compilation time for a big application with lots of modules), but worth
doing.
InputNamelist() returns early if any value list read in by
InputDerivedType() or DescriptorIo<Input>() is empty, since they return
false. But an empty value list is okay, and the early return should
occur only on error.
Fixes https://github.com/llvm/llvm-project/issues/151756.
For more accurate compatibility with other compilers' extensions, accept
a bare exponent letter as valid real input to a formatted READ statement
only in a fixed-width input field. So it works with (G1.0) editing, but
not (G)/(D)/(E)/(F) or list-directed input.
Fixes https://github.com/llvm/llvm-project/issues/151465.
When NAMELIST input takes place on a derived type, we need to preserve
the type in the descriptor that is created for storage sequence
association. Further, the fact that any child list input in within the
context of a NAMELIST must be inherited so that input fields don't try
to consume later "variable=" strings.
Fixes https://github.com/llvm/llvm-project/issues/151222.
An initial commit for #149911, this adds a stub implementation for
dlinfo and the enums list of `RTLD_DI_*` values.
While the dlinfo implementation relies on dynamic linker support, this
patch will add its prototype in the generated dlfcn.h header so that it
can be used by downstream platforms that have their own dlinfo
implementation.
On X86-64, LLVM currently generates the same DWARF debug info for `call
rax` and `call [rax]`; in both cases, the generated DWARF claims that
the call goes to address RAX. This bug occurs because the X86 machine
instructions CALL64r and CALL64m both receive register operands, but
those register operands have different semantics.
To fix it, change DwarfDebug::constructCallSiteEntryDIEs() to validate
the callee operand's semantics (`OperandType`) and make sure it is not
semantically describing a memory location.
This fix will result in less DW_TAG_call_site and DW_AT_call_target
entries being generated.
There is an existing test in dwarf-callsite-related-attrs.ll that
asserts the broken behavior; remove the broken check, and instead add a
new test dwarf-callsite-related-attrs-indirect.ll that checks behavior
for indirect calls.
The existing test xray-custom-log.ll is validating something even more
broken: It checks the debug info generated by a PATCHABLE_EVENT_CALL.
`TII->getCalleeOperand()` assumes that the first argument of a call
instruction is always the destination, but the first argument of
PATCHABLE_EVENT_CALL is instead the event structure; and so we were
emitting debug info claiming the callee was stored in a register that
actually contains some kind of xray event descriptor, and the test
validates that this happens.
I am breaking and deleting this test.
I guess the intent there might have been to validate that we emit
debuginfo referencing the target of the direct call that LLVM emits
(which we don't do)? But I'm not sure.
I find myself doing this alot
```
for (unsigned varIndex = rel.getVarKindOffset(VarKind::Domain);
varIndex < rel.getVarKindEnd(VarKind::Domain); ++varIndex) {
...
}
```
Adding this convenience method so I can instead do
```
for (unsigned varIndex : rel.iterVarKind(VarKind::Domain)) {
...
}
```
---------
Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com>
Update handling of canonical IV resume phi for the epilogue loop to make
sure the resume phi for the canonical IV is always the first phi in the
scalar preheader.
This makes it easier to retrieve it in preparePlanForEpilogueVectorLoop.
For now, we keep an assert to make sure we use the same resume phi as
before. This will be removed in the future.
GlobalVariableOp describes that built_in specifies SPIR-V BuiltIn
decoration associated with the op. The attribute was defined as builtin
in the tablegen (no uderscore). This was causing correct
GlobalVariableOp decorations like: built_in("GlobalInvocationId") to be
saved as a new attribute making it impossible to access the built_in
attribute through getBuiltinAttr.
`PlatformList::Create()` added an item to the list even when
`Platform::Create()` returned `nullptr`. Other methods use these items
without checking, which can lead to a crash. For example:
```
> lldb
(lldb) platform select unknown
error: unable to find a plug-in for the platform named "unknown"
(lldb) file a.out-arm64
PLEASE submit a bug report to...
Stack dump:
0. Program arguments: lldb
1. HandleCommand(command = "file a.out-arm64 ")
...
```
This fixes failures in a number of tests, in the
clang-cl-no-vcruntime configuration (where libcxx provides dummy, no-op
replacements of some vcruntime base exception classes), if building with
optimization enabled.
Previously, with optimization enabled, the compiler concluded that these
fields would be uninitialized at the points of asserts in the tests.
This fixes the following tests in this configuration:
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.dynamic/alloc.errors/bad.alloc/bad_alloc.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.dynamic/alloc.errors/new.badlength/bad_array_new_length.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.exception/bad.exception/bad_exception.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.exception/exception/exception.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.rtti/bad.cast/bad_cast.pass.cpp
llvm-libc++-shared-no-vcruntime-clangcl.cfg.in ::
std/language.support/support.rtti/bad.typeid/bad_typeid.pass.cpp
This patch adds a new set of conformance tests for single-precision math
functions provided by the LLVM libm for GPUs.
The functions included in this set were selected based on the following
criteria:
- An implementation exists in `libc/src/math/generic` (i.e., it is not
just a wrapper around a compiler built-in).
- The corresponding LLVM CPU libm implementation is correctly rounded.
- The function is listed in Table 65 of the OpenCL C Specification
v3.0.19.
Binary I/O (also called buffered I/O) expects bytes-like objects and
produces bytes objects [1]. Switch from using a Python buffer to using
Python bytes to read the data. This eliminates calls to functions that
aren't part of the Python stable C API.
[1] https://docs.python.org/3/library/io.html#binary-i-o
# Problem
`yarn package` cannot be run twice in a row - the second time will error
out:
> Error: ENOENT: no such file or directory, stat
'<path>/llvm-project/lldb/tools/lldb-dap/out/lldb-dap.vsix'
This error is also weird, because the file actually exists. See the end
of this [full
output](https://gist.github.com/royitaqi/f3f4838ed30d7ade846f53f0fb7d68f4).
# Fix
Delete the `lldb-dap.vsix` file at the start of each run. See
consecutive runs [being
successful](https://gist.github.com/royitaqi/9609181b4fe6a8a4e71880c36cd0c7c9).
…rotocol
When writing a custom gdb-remote server I realized that the encoder and
decoder of register formats is incomplete.
- Add the encoder on the server side and add an llvm_unreachable is
there's a missing case.
- Add a decoder on the client side that doesn't fail. We have to keep it
flexible.
I couldn't figure out an easy way to test this but the changes seem very
straightforward to me.
This way we make sure that the logic to reconstruct demangled names in
the tests is the same as the logic when reconstructing the actual
frame-format variable.
`DemangledNameInfo::SuffixRange` is currently the only one which we
can't test in the same way until we set it from inside the
`TrackingOutputBuffer`. I added TODOs to track this.
Also removes an outdated test buffer-array-operator.hlsl. Array operator on resources is tested in StructuredBuffers-subscripts.hlsl and RWBuffer-subscript.hlsl.
`Parser->Run(Opts.NoInitialTextSection)` calls initSections. Remove a
redundant initSections to remove an extra FT_Align fragment, observed
when investigating a missing MCOrgFragment relaxation issue
https://github.com/ClangBuiltLinux/linux/issues/2116
The tma descriptor check does not appear to be correct, as it requires
the last dimension of memref to be 128 bytes. However, the bytes of the
last dimension can be equal to swizzle bytes.
