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.
Tue, Dec 1
Mon, Nov 30
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;
Wed, Nov 25
- add comment suggested by @rnk
- combine Linux and FreeBSD FileCheck
Tue, Nov 24
Thu, Nov 19
Looks ok to me
Wed, Nov 18
Tue, Nov 17
Tue, Nov 10
I'm not sure if we need to add a runtime check?
This is fine with me; have we always done that?
Mon, Nov 9
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.
Sun, Nov 8
Sat, Nov 7
In theory Obj-C is available on other systems
Thu, Nov 5
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.
Wed, Nov 4
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
Sorry- the review is fine as-is. There is some nuance here, but it is better to just mark this unsupported for now (as you've done) and we (FreeBSD) can revisit later when all supported versions do not allow reading dirfds.
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
It will be nice to include in the description what systems were not supported by hard coding 560, if such information can be obtained relatively easily.
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?
Nov 14 2019
Nov 13 2019
Use elf_aux_info() if we can
Nov 8 2019
Out of curiosity what workflow leads to BOMs in linker scripts?
Oct 23 2019
I was under the impression that -P was supported on FreeBSD.
Is this using the system nm? ELF Tool Chain nm does not (currently) support the -P flag.