- User Since
- Jun 4 2014, 10:37 AM (357 w, 5 d)
Tue, Mar 16
Are the syscall_args structures part of the stable KBI? This won't quite cleanly apply to older versions of FreeBSD because at least on x86 the system call entry code has been cleaned up to remove some code duplication, but I am running on 12-STABLE with a version of this that doesn't correctly handle the syscall / __syscall syscalls and it would be great to be able to MFC as much as possible, even if we can't get full support without the KBI change.
- Add missing architecture support, address reviewer comments.
Mar 12 2021
Sorry, this version does work, I had only updated one of the places in the code using it to check si_syscall and so the test was failing yesterday.
Add amd64 paths to preserve the original system call number.
When do you need this? Isn't this kind of introspection warrants a use of real debugger which can deduce all the data from debugging information?
Mar 11 2021
I appear to be setting the field in the siginfo structure incorrectly in the new version, but it's now the end of the day for me so I will try to debug this tomorrow.
@emaste, sorry, I don't think I understand this comment.
Updated based on @kib's feedback.
@kib, thank you, that also mirrors what Linux does for seccomp violation signals. I will update the diff to reflect that.
Mar 10 2021
Feb 1 2021
Thanks, I'll see if I can chase this down later. My commit bit lapsed, please can you land it?
Yes it should be strdup'ed somewhere but I am surprised that it works. Look at the start of load_object(): if name != NULL, it searches for existing loaded object with the specified name.
Thanks. I can confirm that this change also fixes this problem:
Jun 18 2020
For snmalloc, we use this call in the Linux PAL. On FreeBSD, we use mmap to map a new anonymous memory object over the old one, which has the same behaviour. We don't do this on shared memory mappings, but for sandboxing use cases we do need some equivalent mechanism (i.e. something that can zero a large range of shared memory, without requiring the OS to actually allocate physical pages for all of the zeroes). On Linux, we can do this with fallocate on the underlying memory object (I think we can do it with mem_fd objects, we can definitely do it in tmpfs). I am not sure what the correct mechanism for doing this in FreeBSD is.
May 5 2020
Feb 24 2020
Feb 14 2020
This looks fine, but please submit it as a GitHub PR so that it goes through CI (I can't imagine it failing).
Jan 15 2020
Unless I'm missing something, this leaves GPL'd dtc's sources in the tree but removes the ability to build them. Would it make sense to remove the code at the same time as removing the build system goo?
May 25 2019
I've now tried doing this and have finally managed to get it to work. A couple of things:
Mar 26 2019
Mar 15 2019
I'd be very happy to replace the libelftc demangler with the one from libc++abi, but last time this was discussed there were some complaints about the significant increase in binary size. One solution that I'd considered is to replace the demangler in libc++abi with a stub that doesn't actually do any demangling and then import the libc++abi demangler into libc++, possibly excluding it from release builds of the static library (dynamically linked programs probably don't mind paying the size overhead).
Mar 14 2019
Please do not do this. libc++abi implements the Itanium ABI specification, but *not* GNU extensions. This is fine for Apple, because their Objective-C exceptions are thin wrappers around C++ exceptions, but other languages on non-Apple platforms (Objective-C definitely, I think Ada and a few others) rely on GNU extensions. These are supported by libsupc++ and libcxxrt. There's a reason that the product groups at $WORK picked libcxxrt for things that ship libc++...
Feb 10 2019
Feb 3 2019
Jan 27 2019
Jan 21 2019
Jan 18 2019
Dec 31 2018
Dec 29 2018
There may be a few more changes coming. I can now build all of the gnustep-app packages with the new ABI, but sope2 fails to link with some interesting errors.
Dec 28 2018
Oct 12 2018
Aug 17 2018
These changes look fine, but please send a PR on GitHub and then merge to FreeBSD from upstream.
Feb 10 2018
I wonder how we prevent these from getting out of sync (or check their correctness in the first place). How feasible is it to add a dynamic check along the lines of WITNESS that would record these annotations for each block of memory and then check that copyin / copyout were not done past the declared length, or in the wrong direction? I suspect a static analysis would be too hard unless we are willing to propagate these annotations all of the way down into the kernel, unless the copyin / copyout are always done near the system call layer.
Jan 7 2018
I saw something similar. This upgrade first failed because of a samba44 samba46 conflict. Running it again silently removed samba44 (nothing in my scrollback indicates that 4.4 will be removed) and installed 4.6. Not a great user experience.
Dec 13 2017
I don't have an exhaustive list, and even if we fix all of them in the base system, there will be others in ports. This is why we have things like $PAGER - to avoid needing to hard-code defaults. If the project believes that less is a better default pager than more then we should modify /etc/profile or something to set PAGER=less, not go and modify all of the tools by hand to use less (and if there are any tools that don't respect $PAGER, $EDITOR and so on then they are buggy and should be fixed).
I can't help feeling that this poll is really asking the wrong question. There are a bunch of things like this, for example:
Dec 12 2017
What are the changes? I've only ever used less on GNU systems where the more install is ancient and doesn't support scrolling up. I have no opinion if I'm not going to notice the difference, but without knowing what the 'few things less does differently' are I'd vote no to avoid surprises.
Dec 3 2017
Nov 3 2017
I don't have strong opinions about this - hopefully this code can be fixed by some judicious application of svn rm in the near future...
Nov 2 2017
Oct 1 2017
This probably means that we no longer need to expose _DefaultRuneLocale in the header.
Sep 7 2017
Aug 27 2017
Aug 26 2017
Aug 21 2017
Jul 14 2017
Nov 26 2016
Is this bad? Licensing aside, dtc is useful as a cross-build and cross-development tool. We use it extensively on x86 servers that make no use of FDT.
Aug 6 2016
Thank you for all of the time that you've spent on this. __cxa_thread_atexit is not in the latest version of the ABI spec, so it's currently an informal convention between the compiler and runtime library. The compiler doesn't check for failure, so it's probably best to abort for dangerous failures. The compiler-generated code probably should be checking for failure, invoking the destructor for the object, and throwing an exception, but that's something for WG21 to decide.
Jul 22 2016
Mar 13 2016
While I agree that we need this in CheriBSD for experimentation with clang, I'd rather that we didn't put it in FreeBSD head unless we have a desire to make the kernel position independent (I've not looked at how we do modules on MIPS, so this may be a real requirement). On in-order implementations, the presence of the delay slot means that the jal can be resolved in time for instruction fetch to succeed, so we don't use a branch predictor table entry (and we won't accidentally alias with another branch in userspace somewhere). This is likely to have fairly complex performance implications on the variety of MIPS hardware available currently.
Mar 1 2016
Feb 29 2016
Jan 18 2016
Not really. The really correct solution is to introduce a __builtin_secure_bzero() that the compiler knows it is now allowed to elide. Anything else is trying to trick the compiler into thinking that it doesn't know what is happening.
Dec 29 2015
Oct 26 2015
Oct 25 2015
Oct 22 2015
Oct 14 2015
What is the one argument that 'seals the deal' for you?
Oct 13 2015
When building base, we explicitly override the system include and linker paths, so this change will not affect things. When building ports, we explicitly add LOCALBASE to the compiler paths. Obviously, both should be tested carefully with a patched compiler to test.
Oct 8 2015
Sep 19 2015
Sep 3 2015
I did a detailed review, which Phabricator appears to have eaten. I'll try to summarise here, as there was some talk of committing this, and it is a long way away from being ready to go in the tree:
Sep 1 2015
I've done a partial review. This needs a lot more work before it's close to being ready to commit. I stopped after seeing the same logic errors repeated in many functions - there may be new kinds of error, but please fix the ones that are repeated everywhere first.
Aug 13 2015
Aug 9 2015
Aug 7 2015
Jul 29 2015
kmacy has been working on bringing over the notify(3) APIs from Darwin, which appear to provide a superset of this functionality. It would be worth comparing the two and seeing what can be shared between the two. Ideally, the file descriptor returned by notify_register_file_descriptor would be of the same kind as that returned by eventfd and, outside of the Linuxulator (where it needs to be a system call for binary compat), we might be able to implement the eventfd stuff entirely in libc using the same system calls as notify(3).
Jul 4 2015
Jul 2 2015
Jul 1 2015
Fix iconv usage by passing CPPFLAGS to make as OBJCFLAGS
Jun 30 2015
Updated the diff fixing a couple of issues after trying
Jun 20 2015
Jun 18 2015
Phabricator doesn't seem to want to show me the diff, but it sounds sensible. Have we shipped a version in 9/10 that uses this symbol? If so then we should check that old binaries still run with the new .so, otherwise I think it's fine.
May 27 2015
It is problematic for the compiler to differentiate between being invoked as CC and as cc (clang and gcc both have to work on case-insensitive filesystems). The convention to have CC as an alias for c++ comes from some SysV platforms (though not from Linux, which does not install the CC alias). On OS X, cc and CC are the same file, as the filesystem is case preserving but not case sensitive.