Mar 23 2020
Mar 17 2020
Mar 15 2020
Feb 20 2020
Autogeneration of the code puts extra burden on us for tracking what is defined where and for repackaging LLDB with custom build rules (we need plain Makefile in the distribution). I presume the same problem is for gn users, for FreeBSD etc.
Feb 11 2020
Feb 10 2020
Feb 9 2020
Feb 7 2020
Feb 6 2020
systems were not supported by hard coding 560
Feb 5 2020
Feb 4 2020
NetBSD fix landed here:
I will mirror it in NetBSD whatever will be decided here.
For fixing NetBSD, remember to go for #define sigaltstack __sigaltstack14 as the symbol is renamed.
Feb 1 2020
Jan 31 2020
Jan 23 2020
(!defined(__MUSL__) || !__MUSL__) is pretty ugly. There is obviously a need for SANITIZER_MUSL, but then it's up to Linux maintainers whether to accept it.
Jan 13 2020
Jan 2 2020
LLVM Release Schedule: 10.0.0: Jan 15, 2020: branch, then rc1
Jan 1 2020
Dec 27 2019
Dec 26 2019
- rebase to HEAD
Dec 25 2019
Dec 24 2019
Dec 20 2019
@MaskRay I will mail you off-list with one question.
If possible, it would be nice to follow up with heapsort(3) and mergesort(3).
Dec 19 2019
Dec 18 2019
Dec 16 2019
We would like to get this PT_LOAD split as a tunable, ignoring whether tests are passed or not when it is disabled.
Dec 13 2019
Stating it from a different side. If you do not care about GNU ld drop-in replacement property for Linux it's not our business, but we do care about this in NetBSD and we restrict this to our project only (from ELF targets). If you do not care about NetBSD, you shall not care how and whether we use LLD. We try hard to not interfere with Linux looking for a consensus.
@joerg works on the ELF loader and we just need to wait for him. We wrote our temporary patch, but it was not ideal as the long term solution.
We attempted to patch internally LLD rebasing our code for the buildbot purposes but LLD without being used rots quickly, see: https://reviews.llvm.org/D58892
Dec 5 2019
Dec 3 2019
Nov 30 2019
Nov 25 2019
LGTM, since this seems to be the best we can do given the current netbsd behavior.
However, I'd like to repeat what I said on the IRC, that I consider this behavior of netbsd to be unreasonable.
Nov 22 2019
Nov 19 2019
We are in the process of switching our buildbot to newer NetBSD snapshot (-8 to -9) and we keep waiting for this patch to land.
Nov 18 2019
Nov 17 2019
Nov 16 2019
Nov 14 2019
Nov 10 2019
-o is an unportable extension.
Nov 9 2019
Better patch in https://reviews.llvm.org/D70048
- fix a typo in a comment.
Another approach to achieve the same goal as previous attempts. It is already better as it avoids two forks.
Nov 8 2019
How does it deal with security.models.extensions.user_set_dbregs? If there is a handled error than it's fine.
Nov 5 2019
burden with the upstream
I don't want to diverge this patch on offtopic or general discussion.
Nov 4 2019
Nov 3 2019
Nov 2 2019
I still have the feeling that such configurations should be added to clangDriver/gcc specs or a shell script wrapper of lld.
- upload diff with wider context
Oct 22 2019
Same here, I cannot commit.
now I'm stuck on this trying to install cmake.pkg_add: no pkg found for 'libunistring>=0.9.4', sorry. pkg_add: Can't install dependency libunistring>=0.9.4 pkg_add: 1 package addition failed *** Error code 1
For the git part you will need to install mozilla-rootcerts and follow post-install instructions, as otherwise https:// won't work nicely.
I can't get anything to work. I've tried running a local VM with virtualbox but it's networking driver crashes my kernel. I've tried a local VM with VMware but it won't boot netbsd. I've tried AWS but they only have netbsd 7, which is too old. I've tried google cloud, but their image creator script only works for netbsd 9, and python won't build because x11 isn't installed. I've tried installing the pkgsrc binaries from netbsd 8 onto netbsd 9, but that doesn't work either. I'm completely at a loss. I can't figure out how to make a netbsd VM that can actually build LLDB.
Do you have a machine image on AWS or google cloud or even a VMDK or something that I could use?
Oct 21 2019
This looks good as an intermediate step to make lld saner.
Sep 24 2019
Sep 23 2019
Interesting - I had tried to add has_feature for lsan to clang in the past and couldn’t get the change accepted. Nice to see it works now :)
Once GCC will grow support for __SANITIZE_LEAK__ (already pending in review) there will be included as a separate revision support for LSan/GCC.
Sep 21 2019
This is needed in the NetBSD kernel, more fine-grained checks would be acceptable too, but one global feature detection is what I need.