Re: Patches for targeting AArch64 Darwin with clang

[Richard Earnshaw <Richard.Earnshaw@foss.arm.com>]

On 11/01/2021 23:15, Siguza via Newlib wrote:
> Hi
> 
> We at the checkra1n team are using Newlib as the standard library of a pre-boot bare metal execution environment on jailbroken iPhones (i.e. aarch64).
> As our target is using the Darwin ABI and we're building with clang, we had to apply some patches. We'd like to upstream those.
> 
> The first two patches should be uncontroversial. They merely consist of:
> 1. an additional header include (which causes a warning for Linux/ELF targets, but which seems to be fatal when targeting Darwin).
> 2. a change that makes all AArch64 "p2align" directives default to 2 rather than 0 (which I'm assuming is done implicitly anyway for non-Darwin targets?).
> 
> The third patch changes SIMD/Neon register arguments in instructions that move between general-purpose and vector registers.
> This is requires when building with clang, even for non-Darwin targets. As far as I can tell, the "d" in "reg.d[0]" does not appear in the ARMv8 Reference Manual and is a gcc-specific thing. I'm assuming it has no actual meaning and gcc just silently ignores it, but I didn't find any actual documentation on that.
> 
> The fourth patch makes all the AArch64 assembly files compatible with the Darwin ABI. In particular:
> - The .type and .size directives are illegal for Darwin targets, so they are wrapped in "#ifndef __APPLE__" blocks.
> - Macro invocations must separate arguments by commas, otherwise they are concatenated and treated as one argument. This should work on all targets and not require any ifdefs.
> - Darwin prefixes C symbols with an underscore, so the assembly for e.g. memcpy has to use _memcpy as label. I figured the least invasive patch for this was to just #define these symbols when targeting Darwin.
> - In one case there was a "b.hs memcpy". Darwin seems to not allow jumping to external labels in conditional branches, so I replaced that with a conditional jump to a local label, followed by an unconditional jump to the external one.
> 
> Please find the patches attached below.
> 
> - Siguza
> 

Please separate this out into individual patches for each issue.  It's
difficult to review it when it's all mixed together and for longer term
maintenance we'll probably want to commit the changes separately as well.

The best way to handle label prefixes for public functions is to define
something similar to the way the Arm port does this.

#define CONCAT(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b

#ifdef __USER_LABEL_PREFIX__
#define FUNCTION( name ) CONCAT (__USER_LABEL_PREFIX__, name)
#else
#error __USER_LABEL_PREFIX is not defined
#endif

I'd expect your C compiler to define __USER_LABEL_PREFIX__ appropriately
for your platform (GCC does this anyway).

Now you can just wrap all public names with FUNCTION() and the
preprocessor will handle this automatically.   This is significantly
preferable to littering the code with platform-specific ifdefs.

R.

> 
> 
> From 461d0a53041b94d23c3dd76b785b60b675ebdaa5 Mon Sep 17 00:00:00 2001
> From: Siguza <siguza@siguza.net>
> Date: Mon, 11 Jan 2021 22:47:57 +0100
> Subject: [PATCH 1/4] Fix include of _memalign_r in aligned_alloc.c
> 
> ---
>  newlib/libc/stdlib/aligned_alloc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/newlib/libc/stdlib/aligned_alloc.c b/newlib/libc/stdlib/aligned_alloc.c
> index feb22c24b..ad8887bd0 100644
> --- a/newlib/libc/stdlib/aligned_alloc.c
> +++ b/newlib/libc/stdlib/aligned_alloc.c
> @@ -26,6 +26,7 @@
>     NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>     SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */
>  
> +#include <malloc.h>
>  #include <reent.h>
>  #include <stdlib.h>
>  
>