[libc][math] Refactor sqrt to header-only (#178335)
This refactors `sqrt` to be header-only, following the libc math
refactoring plan.
Part of #147386
Closes #177648
[lldb] Add support for ScriptedFrame to provide values/variables.
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178575, branch: users/bzcheeseman/stack/6
[lldb] Add conversions for SBValueList and SBValue to the python bridge.
This patch adds support for:
- PyObject -> SBValueList (which was surprisingly not there before!)
- PyObject -> SBValue
- SBValue -> ValueObjectSP using the ScriptInterpreter
These three are the main remaining plumbing changes necessary before we can get to the meat of actually using ScriptedFrame to provide values to the printer/etc. Future patches build off this change in order to allow ScriptedFrames to provide variables and get values for variable expressions.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178574, branch: users/bzcheeseman/stack/5
[lldb] Move ValueImpl and ValueLocker to ValueObject, NFC.
This patch moves ValueImpl and ValueLocker to ValueObject.{h,cpp}. This follows the example set in TypeImpl/SBType, where we have something that SBType uses internally that needs to be exposed in the layer below. In this case, SBValue uses ValueImpl, which wraps ValueObject. The wrapper helps avoid bugs, so we want to keep it, but the script interpreter needs to use it and said interpreter is conceptually *below* the SB layer...which means we can't use methods on SBValue.
This patch is purely the code motion part of that, future patches will actually make use of this moved code.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178573, branch: users/bzcheeseman/stack/4
[lldb] Add support for ScriptedFrame to provide values/variables.
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178571, branch: users/bzcheeseman/stack/3
[lldb] Add conversions for SBValueList and SBValue to the python bridge.
This patch adds support for:
- PyObject -> SBValueList (which was surprisingly not there before!)
- PyObject -> SBValue
- SBValue -> ValueObjectSP using the ScriptInterpreter
These three are the main remaining plumbing changes necessary before we can get to the meat of actually using ScriptedFrame to provide values to the printer/etc. Future patches build off this change in order to allow ScriptedFrames to provide variables and get values for variable expressions.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178570, branch: users/bzcheeseman/stack/2
[lldb] Move ValueImpl and ValueLocker to ValueObject, NFC.
This patch moves ValueImpl and ValueLocker to ValueObject.{h,cpp}. This follows the example set in TypeImpl/SBType, where we have something that SBType uses internally that needs to be exposed in the layer below. In this case, SBValue uses ValueImpl, which wraps ValueObject. The wrapper helps avoid bugs, so we want to keep it, but the script interpreter needs to use it and said interpreter is conceptually *below* the SB layer...which means we can't use methods on SBValue.
This patch is purely the code motion part of that, future patches will actually make use of this moved code.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178569, branch: users/bzcheeseman/stack/1
[Offload][AMDGPU] Fix olQueryQueue uninitialized output parameter (#178464)
## Summary
- Fix uninitialized output parameter in `olQueryQueue_impl` when
`Queue->AsyncInfo->Queue` is null
- Set `IsQueueWorkCompleted` to `true` when no underlying queue exists
(no pending work)
- Resolves test failure on AMDGPU for
`olQueryQueueTest.SuccessEmptyAsyncQueueCheckResult`
Fixes #178462.
## Test plan
- [x] Fixed
`OffloadAPI/queue.unittests/olQueryQueueTest/SuccessEmptyAsyncQueueCheckResult/AMDGPU_AMD_Radeon_RX_7700_XT_0`
test
- [ ] CI tests pass
---------
[2 lines not shown]
nvpair: chase FreeBSD xdrproc_t definition
As of FreeBSD 16, xdrproc_t will take exactly two arguments in both
kernel and userspace in line with the Linux kernel.
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Reviewed-by: Alan Somers <asomers at freebsd.org>
Signed-off-by: Brooks Davis <brooks at capabilitieslimited.co.uk>
Closes #18154
[LoongArch] Support `preserve_none` calling convention
Add support for the `preserve_none` calling convention on LoongArch.
Registers `R4-R20` and `R23-R31` are treated as caller-saved and may be
used for argument passing, except for `R31`.
[LoongArch] Support `preserve_none` calling convention
Add support for the `preserve_none` calling convention on LoongArch.
Registers `R4-R20` and `R23-R31` are treated as caller-saved and may be
used for argument passing, except for `R31`.
[NFCI][ELF][Mips] Refactor MipsGotSection to avoid explicit writes (#178561)
Splitting the VA / addend calculations between build and writeTo means
having to keep them in sync and duplicating some of the logic. Move all
such calculations into build, mirroring how the normal non-MIPS code in
Relocations.cpp ensures the addend and initial memory contents are set.
Add support for DW_FORM_GNU_ref_alt and DW_FORM_GNU_strp_alt. (#176056)
LLDB's DWARF parser didn't support parsing DW_FORM_GNU_ref_alt and
DW_FORM_GNU_strp_alt forms which would cause any file loaded by LLDB to
fail to parse any DWARF. Added support for parsing this information
only, not for actually finding the debug info reference to an alternate
file or a string in an alternate file. These extensions are used by DWZ
files which are present in some linux distros, so it will be good for
LLDB to just be able to parse these without emitting an error like:
(lldb) b bar
warning: (arm64) /tmp/a.out unsupported DW_FORM values: 0x1f20 0x1f21
