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?

I've now tried doing this and have finally managed to get it to work. A couple of things:

In D19566#422302, @jhb wrote:

I had labored under the incorrect assumption that libcxxrt was somewhat abandoned and that all other libc++ consumers used libc++abi, however, it seems that it's only Apple and OpenBSD that use libc++abi. NetBSD still uses libcxxrt. Also, when I compared the repositories both libcxxrt and libcxxabi had basically no real activity in the last two years. libcxxabi had more commits, but they were all due to relicensing and moving to monorepo.

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).

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++...

In D17529#405556, @kib wrote:

I am going to commit this shortly, with 'Submitted by: theraven'.

In D17529#403296, @kib wrote:

Yes, I agree from reading of the code. I suspect that I left the chunk because I wanted to keep dlopen() handling as is, but later added the initlist_objects_ifunc() call in dlopen_object().

If you can test that the latest amd64 head boots multiuser with your change applied, please commit and MFC to 12+11.

In D17529#403239, @kib wrote:

In D17529#403212, @theraven wrote:

In D17529#374132, @kib wrote:

I think you somehow failed to provide the explanation of your case. Esp. the last paragraph of the description is confusing, please recheck the order of dependencies and order of resolution and correct it so I can understand. Better yet, provide the minimal example of the self-contained code which demonstrates the issue.

Sorry for the delay in getting back to this. I hoped that D18400 would fix it, but now that I've upgraded to 12, I'm still seeing the issue. We have a library that exposes a function with an ifunc resolve. The ifunc resolver calls another function in the same library, via the PLT. When a second library links against our library and includes a non-PLT relocation for our ifunc symbol, our ifunc resolver invokes a function via a PLT stub, but the PLT stub is not yet initialised and so this dies.

The problem is in libexec/rtld-elf/amd64/reloc.c where, in reloc_non_plt, it calls rtld_resolve_ifunc without checking that defobj is relocated. Adding this before the call is almost certainly the wrong solution, but does address the problem:

if (!defobj->relocated)
    relocate_object(__DECONST(Obj_Entry *, defobj), false, obj_rtld, flags & ~SYMLOOK_IFUNC, lockstate);

I think the correct fix most likely involved doing something a little bit closer to this, and deferring ifunc resolution until after the library implementing the ifunc has had its non-ifunc relocations applied.

This is exactly how the current rtld ifunc resolution works:

• first all objects gets their non-plt non-ifunc relocations resolved.
• second all objects gets their ifuncs resolved, including plt resolution if LD_BIND_NOW.
• third pass where init functions are called.

The second pass (for ifuncs) is performed in the reverse-init order, same as the third pass.

In D17529#374132, @kib wrote:

I think you somehow failed to provide the explanation of your case. Esp. the last paragraph of the description is confusing, please recheck the order of dependencies and order of resolution and correct it so I can understand. Better yet, provide the minimal example of the self-contained code which demonstrates the issue.

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.

These changes look fine, but please send a PR on GitHub and then merge to FreeBSD from upstream.

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.

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.

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:

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.

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...

This probably means that we no longer need to expose _DefaultRuneLocale in the header.

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.

All sounds sensible to me.

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.

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.

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.

Hi Jim,

What is the one argument that 'seals the deal' for you?

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.

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:

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.

LGTM.

kmacy has been working on bringing over the notify(3) APIs from Darwin[1], 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).

Address iconv issues.

Fix iconv usage by passing CPPFLAGS to make as OBJCFLAGS

Updated the diff fixing a couple of issues after trying

In D2961#57789, @antoine wrote:

I can do an exp-run too, I don't know if you tested all ports depending on gnustep?

Comments inline.

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.

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.

Hmm, that doesn't look as if it should break. The macros still expand to an integer constant expression. You'll lose the type checking when you do this, but the initialisation should still work. What is the compiler error that you see?

What things needed rewriting to work with this?

These look fine, but it would be nice to have some way of telling whether we've got all of them. For example, most of the sig* functions don't appear to define in their man pages what a null sigset_t means, so why do only some of them get the attribute?

Thank you!

Looks good to me.

Please can you submit the fixed version of this as a pull request upstream too, and I'll approve it there so that we don't have more pain merging the next time.

Looks good to me.

Or, right, sorry. I misunderstood and thought it was being moved into private. Reading it a bit more carefully, it looks fine.

If gdb is the only in-tree consumer of libreadline, can we just statically link it into gdb and remove the .so entirely?