- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 5 2022
Jul 1 2022
Jun 29 2022
Jun 28 2022
I've not tested this on a system that manifests the original issue due to lack of easy access last Friday, but it's straightforward, fixes build for me on MacOS, and works on example input.
Jun 21 2022
Jun 20 2022
Jun 17 2022
All the prerequisites for this change have now landed. We'd like to get this in to reduce diffs to CheriBSD before we add support for multiple libcompat ARCHs in the same buildworld.
Jun 16 2022
Jun 15 2022
Jun 13 2022
Jun 6 2022
Jun 1 2022
Upstream accepted the first version of this patch as https://reviews.llvm.org/D126710
May 31 2022
May 26 2022
May 25 2022
- Switch to building the locked version
May 24 2022
In D35311#800370, @brooks wrote:This seems a bit problematic in that the set of available symbols depends on the compiler building the tree. It may be that we want to generate them and emit the function without the if (lockfree(ptr) path instead.
In D35311#800371, @arichardson wrote:Adding downstream patches is not great but I think in this case it's reasonable. Although maybe upstream would be happy with this too, I'm not sure what the supported compilers for compiler-rt are.
This seems a bit problematic in that the set of available symbols depends on the compiler building the tree. It may be that we want to generate them and emit the function without the if (lockfree(ptr) path instead.
May 23 2022
May 20 2022
May 19 2022
May 18 2022
May 17 2022
May 5 2022
May 4 2022
May 3 2022
Overall this change seems generally well contained for something that touches most syscalls. There are a few things that seem stray that I've noted.
Apr 28 2022
Apr 27 2022
Apr 25 2022
Apr 20 2022
Apr 18 2022
Apr 15 2022
PR with a better split https://github.com/freebsd/freebsd-src/pull/597
Apr 14 2022
I agree with @jhb on the naming. I've introduced a couple following this convention in R10:28f047188492c8f2ddca66f162fd2ac9bdc170a6 and I've got another ~50 in my CheriBSD tree. That probably does require squashing this commit with D34850.
Apr 13 2022
Apr 11 2022
In D34761#789755, @sigsys_gmail.com wrote:In D34761#789689, @brooks wrote:A few thoughts about integration with syscalls.master:
- The if SYSFIL values aren't in syscalls.master they people won't remember to add them. This happened all the time with CAPENABLED annotations when it was in a separate file.
Should the per-sysfil short description comments be moved there too? It would put them right where they're needed the most. The Linuxulator could use sysfils too though (I had it working for a while but I didn't keep its syscalls.master files up-to-date as I kept rearranging the sysfils..).
Apr 8 2022
I've done x86-ification patches with a split of combining that that have high level of duplication and punting the i386 version to a new x86/i386 directory where there is little commonality. I'll post them, likely as a GitHub PR since it's a bunch of mostly boring changes I want to be separate commits for revertability.
This one is perhaps the most debatable one since #warning isn't standard, but we've got plenty of unguarded uses.
We compile as for C99 so inline is supported and all modern compilers support __inline.
I can't find any instance of __NO_GNUC_VA_LIST in the world so I'd be tempted to drop it, perhaps in another commit.
typeof will even be in C23 as a literal (no _Typeof or the like)
FWIW, the system literally won't compiled without __GNUCLIKE_ASM defined due to pcpu.h
FYI, I've got a separate diff to remove the sys/cdefs.h include entirely since it's pointless.
A few thoughts about integration with syscalls.master:
- The if SYSFIL values aren't in syscalls.master they people won't remember to add them. This happened all the time with CAPENABLED annotations when it was in a separate file.
- I'm worried that there are enough values that people are just going to punt and not add any flags so this will be an ongoing maintenance burden even with integration into syscalls.master.
Mar 31 2022
Mar 29 2022
Mar 28 2022
In D34696#786246, @jrtc27 wrote:Relying on the include guards to avoid the need for an #else seems a bit gross... and tbh I'd rather these did get the x86 treatment, you could surely automate it
Adding powerpc as this effect powerpc64 and I can't test it (the comments about -m32 are only about amd64, powerpc64 builds without additional changes)