Am I guessing correctly that this happens when you installed combined llvm+lldb build, and then try to build lldb standalone against that?
Hmm, I've just looked through CMake docs, and I think a better solution might be:
Fri, Jul 12
Something that we do not cover here is that once a tracee reports a signal (like someone poked it with SIGUSR1) and we want to pass it over to the tracee, we will reset siginfo.
This scenario should be covered by a test and we should handle it properly..
The solution in NetBSD for passing over signals without changing siginfo, is to not calling PT_SET_SIGINFO as the default one will be kept by the kernel. Optionally pick old siginfo with PT_GET_SIGINFO and optionally change destination lwp.
Tue, Jul 9
The build bots must specify -DLIBCXX_CXX_ABI=libcxxabi at the CMake configure step. Otherwise, they'll end up using the default ABI library on Linux, which uses the xxx_fallback.ipp files from libc++, and that doesn't implement everything we need.
Unless I'm mistaken, this commit broke building Polly:
Mon, Jul 8
Could you tell me specifically what change to buildbot is requested? I must've missed the original thread.
Am I guessing correctly that this broke the buildbots (again)?
Sun, Jul 7
LGTM. According to CMake manual, plain + is the only correct form and if \+ worked at all, it was probably only by accident.
The API has changed, and so the patch is no longer correct.
Sat, Jul 6
This seems to have broken the build for us:
Tue, Jul 2
Mon, Jul 1
Updated per review.
I'm going to ask Kamil to stamp those patches anyway but I always appreciate your advice wrt LLDB coding style and general integration. After all, we all want LLDB codebase to be more unified.
That's probably one of the reasons why NetBSD normally prevents unprivileged users from setting DRs.
Sat, Jun 29
I'm sorry that nobody has replied to your request earlier. AFAICS the libcxx code has changed. Does it work now, or do we need to make thread_win32.cpp conditional to LIBCXX_HAS_WIN32_THREAD_API still?
Thu, Jun 27
This is ready to be reviewed now.
Wed, Jun 26
Removed XFAIL for tests fixed by this.
Tue, Jun 25
Mon, Jun 24
Fri, Jun 21
…and removed stale declarations.
Updated to use new XState conversion methods.
It's not much, but it definitely does help.
// NB: I have no clue why FreeBSD code claims to belong in 'POSIX', and Linux does not.
I think that somehow fell out of the fact that FreeBSD uses an in-process debugging plugin, while linux uses lldb-server.
Thu, Jun 20
How about this? I've removed almost all abstraction, leaving only simple ptrace() wrapper.
I'll try to simplify it in a few steps and see how that goes. All I'm saying is that ultimately having some DoRegisterSet() wrapper that calls ptrace() and avoids repeating getting PID/TID may help. Though admittely it saves very little actual code.
BTW, is ReadGPR even called from some other place than NativeRegisterContextNetBSD_x86_64::ReadRegisterSet ? If not, then we could remove all of these functions (except the ReadRegisterSet I suggest above), and inline everything into NativeRegisterContextNetBSD_x86_64::ReadRegisterSet (one of these should be renamed, obviously), removing about 5 layers of indirection...
Maybe have GetYMM(unsigned num, YMM& reg)/SetYMM(unsigned num, const YMM ®) methods on the XSAVE struct ?
We have the same XSTATE<->YMM conversion functions in NativeProcessLinux. It would be nice to extract them to some common place (Plugins/Process/Utility, I guess :P).
Rebased for changes in NativeRegisterContextNetBSD_x86_64::GetSetForNativeRegNum(), and removed the conditions there.
@stella.stamenova could you try running the lldb invocation manually like I did? I'm wondering if you're getting the same issue.
The added test broke NetBSD buildbot: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/109/steps/run%20unit%20tests/logs/FAIL%3A%20LLDB%3A%3ATestProcessAttach.test
Wed, Jun 19
Jun 17 2019
Marshall, std/containers/associative/map/map.cons/deduct_const.pass.cpp test seems to be reliably failing from commit one on both Gentoo Linux and NetBSD. Could you please look at the classical example of totally cryptic C++ error? ;-)
This check should contain additional check for uid==root. If we are root we can read and write to DB registers.
Removed stale decorator.
Updated as suggested above.