User Details
- User Since
- Feb 27 2015, 12:34 AM (389 w, 1 d)
Aug 24 2021
May 23 2019
The patch looks pretty good as far as I can see. That said, I've been out of the loop for quite a while, so do take my approval with a grain of salt.
May 22 2019
Mar 29 2019
Mar 18 2019
Thanks for working on this!
Mar 14 2019
Mar 10 2019
Feb 1 2018
Jan 31 2018
This effectively reverts rL295240, right? If so, I'd personally oppose to this change.
Jan 9 2018
Dec 27 2017
Dec 5 2017
Sep 21 2017
Sep 20 2017
Hey! Sorry for the breakage. I thought I did a good job of testing this change on various operating systems, but somehow this still fell through the cracks. Odd.
Jun 25 2017
Jun 19 2017
Final call: do any of you have any more feedback on this change? If not, I will go ahead and commit this change one of these days (together with D32937).
May 22 2017
May 20 2017
These changes look all right to me, except that I'd like it if someone else could take a look at Ananas.cpp as well. Is anyone interested in taking a look?
This change looks good to me. Does anyone mind if I were to commit this?
Mar 16 2017
Mar 14 2017
Worth mentioning: the latest version of macOS now supports clock_gettime(). Maybe better to leave the code as is and simply axe the Mach time code at some point in the future?
Mar 9 2017
Mar 7 2017
Mar 5 2017
Feb 23 2017
Feb 21 2017
Any more feedback before I commit this change to the trunk?
Restore comment that was lost during sync to latest code.
Feb 20 2017
Remove numbers from llvm-readobj output to make test future proof.
Feb 15 2017
Feb 13 2017
Sync to latest codebase.
Feb 11 2017
Feb 2 2017
Friendly ping! :-)
Dec 30 2016
Dec 29 2016
Dec 28 2016
I'd be interested in seeing a feature like this appearing. Any chance this feature may be part of Clang 4.0?
Dec 24 2016
Also an interesting observation: _LIBUNWIND_IS_BAREMETAL seems to be used only in this single source file and only provides an implementation for ARMv6.
Dec 23 2016
Add a comment after the 'else' to indicate this code applies to ARM.
Interesting observation: dwarf_index_section_length stores the length of the section, whereas arm_section_length stores the number of entries in the section. This feels a bit unnatural in my opinion. Should this be tackled in this change as well, or do we want to do this separately?
Dec 18 2016
I'm the author of FreeBSD's utmpx. LGTM!
Nov 16 2016
Sep 28 2016
Sep 22 2016
Not that it helps much, but with this patch I can at least get all of the packages for CloudABI to build on ARMv6. I can't test whether the resulting binaries work yet, as I'm at a conference. I will be able to test this for you on Monday.
Sep 5 2016
Aug 20 2016
Aug 13 2016
Aug 11 2016
I just experienced this error while trying to build glib for i686.
Jul 2 2016
Friendly ping. :-)
Jun 16 2016
May 3 2016
Seems to fix the issue. Thanks!
Apr 9 2016
I've just built a copy of LLVM and Clang with these patches applied. With that compiler I did a full rebuild of all core CloudABI libraries, including the C library's unit test suite (~1000 tests), with -fstack-protector-all and SafeStack enabled. All unit tests still seem to pass.
Apr 6 2016
Thanks for working on this! I know too little of LLVM internals to review this change properly, but I'd be more than happy to run our C library test suite against this. Could you also send out the patch for Clang you mentioned, so I can test this?
Apr 5 2016
Okay. Now that my other change has landed, I think we can go ahead with this change as well. Any thoughts?
Put tls-initial-exec-local.s back in now that the GOT works properly.