- User Since
- Jul 24 2013, 5:36 AM (390 w, 6 d)
Mon, Jan 4
For now, only Linux/ARM64 is supported/tested.
Thu, Dec 31
Mon, Dec 28
Sun, Dec 27
Dec 16 2020
I think it's ok to only warn on Windows.
IMO that's sensible
Dec 6 2020
Seems reasonable to me
Dec 4 2020
Ah, of course. SGTM.
No objection here. I'm curious why the two modified tests work on Linux or NetBSD today though?
Dec 1 2020
How do things go wrong on Darwin? I was under the impression that this was implemented in LLVM as strictly inline code, no runtime support required.
Nov 30 2020
One thing that FreeBSD should do, is to upgrade to the protocol version 1 (stored in r_version), like Linux, NetBSD and OpenBSD.
Link to Linux info:
I'm curious how gdb handles this, and asked @bsdjhb if he knows off hand.
No objection, but maybe add a comment explaining the status of this implementation? Does/will NetBSD do the same?
Can we add a test that the feature can be enabled on an OS other than Linux / Windows / Darwin?
Abandon in favour of D92245
if (EffectiveTriple.isOSWindows() || EffectiveTriple.isOSDarwin()) return;
Nov 25 2020
- add comment suggested by @rnk
- combine Linux and FreeBSD FileCheck
Nov 24 2020
Nov 19 2020
Looks ok to me
Nov 18 2020
Nov 17 2020
Nov 10 2020
I'm not sure if we need to add a runtime check?
This is fine with me; have we always done that?
Nov 9 2020
No objection from me but I haven't been sufficiently involved in lldb's tests to approve.
Agree that even if refactoring is needed correcting these makes sense.
Nov 8 2020
Nov 7 2020
In theory Obj-C is available on other systems
Nov 5 2020
How does Windows fit into this? Other than that Q, LGTM.
Does Linux fetch each time also?
I agree it's probably not worth the effort.
What do you suggest? Is it fine to go with my results for as long as I work on it? I can update it to match CI/buildbot results later.
Nov 4 2020
When running locally with this change applied I get:
I added comments in the now-dereferenced bugs linking back to this review - most of them were submitted by me, and I'll double check and close them once this lands.
Nov 2 2020
Oct 30 2020
There is TestProcessAttach.py that has an @expectedFailureNetBSD but no FreeBSD annotation, as well as TestCompletion.py, but I don't see these in the failing list.
running clang -target x86_64-unknown-freebsd13.0 -split-dwarf foo.c indeed produces a foo.dwo and foo.o w/o invoking objcopy
Oct 21 2020
Oct 15 2020
Looks fine to me
Oct 13 2020
Looks reasonable to me and currently fails (as expected) on FreeBSD.
fine with me
fine with me
Sep 30 2020
Aug 28 2020
Aug 26 2020
It looks like this conflicts with OpenSSL's compiler version check
Aug 25 2020
Aug 22 2020
Aug 18 2020
Ah if you use _LIBUNWIND_USE_FRAME_HEADER_CACHE instead (i.e., a _ between FRAME and HEADER) it will match the workaround committed to FreeBSD.
Looks reasonable to me.
Jul 27 2020
Jul 24 2020
LGTM, we acquired our strstr from musl
Jul 12 2020
Fine with me
Jul 3 2020
Jun 29 2020
Jun 25 2020
some nitpick comments. I'm not familiar with z/OS's APIs here so not qualified to fully review the change in getMainExecutable but seems reasonable
Jun 12 2020
May 30 2020
I'm now adding support in FreeBSD, e.g. https://reviews.freebsd.org/rS361657
May 7 2020
I will commit this shortly (and then merge the change into FreeBSD's copy).
May 2 2020
Apr 20 2020
Looks ok to me
Apr 2 2020
Apr 1 2020
Mar 21 2020
Feb 7 2020
Feb 6 2020
Dec 16 2019
Nov 18 2019
Nov 17 2019
Should have a test added
Nov 15 2019
I think the default policy discussion might be better had on llvm-dev than a Phab review.
Shall we default to -mbranches-within-32B-boundaries if the specified -march= or -mtune= may be affected by the erratum?