From owner-freebsd-arm@freebsd.org Thu Oct 8 23:57:38 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B5DDF434251 for ; Thu, 8 Oct 2020 23:57:38 +0000 (UTC) (envelope-from mw@semihalf.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C6p6T4pKpz4dLl for ; Thu, 8 Oct 2020 23:57:37 +0000 (UTC) (envelope-from mw@semihalf.com) Received: by mail-qt1-x82f.google.com with SMTP id g3so6639727qtq.10 for ; Thu, 08 Oct 2020 16:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0pJ4bSsVL9QLhFHIg1T5tMFdcE740KCMdaGv50oht20=; b=LKYqmy1yc3Fubo6ywV+bRN/l8J5vNFBztNCe77eiHqKwOSiZiqjZ9FDePNvvDr3VWE nu/0YgZUIZamxdNn+afoc+fcu76bo1BDYChc2daJmhOlFBKgGTVaUApiYUJSHtVVTKTl MoSNcU1ZFiEYFPVLYvHONAIJAfLVVRtFV8QSfEw8vnXp14sPGFVIoLNrfzXpQIS+C76u pe2Pv+uc+4MBp5MhGKW+1PEbfE4dMTSZrqNHNhhrT0i6NUIwVi2mOsmpN9qY+Ipq0vZB KaL3CA72RHkZSoraGcLoEYctICSKxQ0rFYZYvQKIr7o7ZZu93lW27F1KuqGN6JQRZkiv 8j/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0pJ4bSsVL9QLhFHIg1T5tMFdcE740KCMdaGv50oht20=; b=FfP5HhQzn9W0zopdGyFkzswIbkBFT7YiwdWsAyrg1QkLeKZd3jt4OlC1N87IrvZIve hvxJOJIoDMnGm+C4LJMGwFeYOaDzUqhmowm/z25RxeQcK5M/lr7THa/C8P8vw3KZVmni ium228njUKgrbdg7KKuSUBCtHMxPkUAvfAf+ZQWiMDXGkE5AH2fPzl9viZCE3c1HOqaP C8kQkoc5q2YpKFUeaJiGz3IQ+ugC1DbWjxRQrY2eRBiwFr5cOhz8u3TjDNcn/aFbto1u /1eGGNaZcIkDTB2C9PERxm4Zb2lgaSt3CpZk9lh0cEPcXk5EfLAm16BOfm3MVxbTouop U4SQ== X-Gm-Message-State: AOAM531iakG4O86er7i9+fBt28rCMj4VAQLYJ8OWUsiuglsD0zLiGJxG sRbIVgGcX403rn+75mgycT5RCYqWtWPaC8KxEzREL2j5WolY/A== X-Google-Smtp-Source: ABdhPJz42wMzb1z8BFDNgdUswFuiQyo+u6nA3JhI0hlDOx7HmiAYM73MO3hfCyz2ba/2ywGOm/beM4KMTNboW7AbRuo= X-Received: by 2002:aed:3f16:: with SMTP id p22mr11425481qtf.181.1602201456067; Thu, 08 Oct 2020 16:57:36 -0700 (PDT) MIME-Version: 1.0 From: Marcin Wojtas Date: Fri, 9 Oct 2020 01:57:22 +0200 Message-ID: Subject: ARMv7 without VFP To: freebsd-arm Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4C6p6T4pKpz4dLl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=LKYqmy1y; dmarc=none; spf=none (mx1.freebsd.org: domain of mw@semihalf.com has no SPF policy when checking 2607:f8b0:4864:20::82f) smtp.mailfrom=mw@semihalf.com X-Spamd-Result: default: False [-2.36 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[semihalf-com.20150623.gappssmtp.com:s=20150623]; FREEFALL_USER(0.00)[mw]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.991]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; DMARC_NA(0.00)[semihalf.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.76)[-0.764]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[semihalf-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.30)[-0.302]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82f:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 23:57:38 -0000 Hi, We have a CA9-based SoC that for some reason does not support the VFP and would like to run the OS on stable/12. Disabling the VFP in the kernel options (or adding the detection of the feature in runtime) seems to work fine, but it turned out the biggest obstacle is trying to force the userspace to use the softfloat libc callbacks (in theory soft-/hard- float usage should be resolved dynamically by linking the proper functions in libc - so far we found no way to compile it successfully though with the standard toolchain). Other approaches to hardcode the softfloat userspace have failed so far. Details can be found below. Is there any known way to compile the userspace that may work with the soft-float on armv7? Details: When booting without VFP there is a problem with almost every process receiving SIGILL signals. Core dumps and disassembly proved that the illegal instructions are associated with hardware FPU. The kernel seems to run fine otherwise. 1. When building world with option CPUTYPE=soft, libc cannot be linked properly due to lack of _aeabi* --- all_subdir_sbin --- ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_f2iz_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fadd_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmpeq_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmpge_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmpgt_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmple_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmplt_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fcmpun_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fdiv_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fmul_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_fsub_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_i2f_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_d2f_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_d2iz_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dadd_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dcmpeq_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dcmpge_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dcmpgt_vfp ld: error: /usr/home/dgr/src/freebsd-src-obj/usr/home/dgr/src/src/stable12/arm.armv7/tmp/lib/libc.so.7: undefined reference to __aeabi_dcmple_vfp 2. According to imp@, the softfloat system can still be built, however it is not officially supported anymore (https://lists.freebsd.org/pipermail/freebsd-arch/2017-September/018329.html). It is assumed that armv6/armv7 CPUs always have VFP unit. 3. FreeBSD stable/12 world with CPUTYPE=soft is built automatically with -mfloat-abi=softfp, which emulates the soft float ABI, however still uses hard float instructions. 4. When trying to pass -mfloat-abi=soft, everything is built with three flags: -mfloat-abi=soft -mfloat-abi=softfp -mfloat-abi=softfp. 5. Additional problem encountered when trying to use additional flag -mfloat-abi=soft: --- clang.full --- /home/mindal/obj/arm.armv6/usr/home/mindal/git/freebsd-src/lib/clang/libclang/libclang.a: could not read symbols: File format not recognized c++: error: linker command failed with exit code 1 (use -v to see invocation) 6. Problems above seen on both stable/11 and stable/12. In case of stable/12 it is visible with both TARGET_ARCH=armv6 and TARGET_ARCH=armv7 I'd appreciate any feedback. Best regards, Marcin (mw@)