From owner-freebsd-arm@freebsd.org Fri Feb 19 23:40:44 2021 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 D972C544B82 for ; Fri, 19 Feb 2021 23:40:44 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dj7P71NLqz3n9X; Fri, 19 Feb 2021 23:40:42 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) ARC-Seal: i=1; a=rsa-sha256; t=1613778030; cv=none; d=strato.com; s=strato-dkim-0002; b=sdRrMb6fPUlvS9U6WxxLKqUplPwHFX1r6v+nH3M3jIKnq8DuWFGzO+jlbIQNWHh06G TqAeANEQ6LmmasWdafNT7x2tRe79obHtdNfVJG9C1HibUpyovTTdZ+dOdil0kxvPLFQ5 kSrVJdHxVUCu1BsdzTPyxRzDJgdmrdFAH4stlQKiQ9oEP7b7H1fz7Yg3ZeAzA9xs4GzD +IItbg2ps7o6Xoi174TgQKoZZlqD6SHkrJUVzpncmI+poR5pxl0S6YyZqdcrui5GRG5E JX6CjvAKXNqKmbrMMpx3H2Sv+d+ZB4nTGWNKDkENqd1jcPZ+VKHE3qmBMt5KsOnynupX qM9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1613778030; s=strato-dkim-0002; d=strato.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date: From:Subject:Sender; bh=U0FZdU+BatMctkzilMcLQdi1KHjI5lzBFymTN90TE/c=; b=sNXyhLqzjvCbNB1wN+STKcglRZR0Vg7UruM+y+ig8dWPlCyT3WcdPsAseT29bqgZs+ IILDjoQCFic7RzhXmVjrP9PvGj616B7b9APmY8Ygj7wQu4M6TZ8S+ZyrZMxRov3kBNLX 1rbndxMFu7SLbfScxdO15rQ6Souryi41FzVb2f18QM0ho6+RzSbCKcEDF9PCo9hhC24n UcpRSb3EmZ+I+q4wB8SFeWsEfim1lRM6HCkUClAeFnp+vjCepHw/Qd5Y1qRBfHr4j1t6 HeaaE3eNnVCaqonByxqWYcFaXz7rpSqUqtrjgtcOMPKOvn17ZXnQO5X79RlUUPLUYj95 cXzQ== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1613778030; s=strato-dkim-0002; d=obsigna.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Cc:Date: From:Subject:Sender; bh=U0FZdU+BatMctkzilMcLQdi1KHjI5lzBFymTN90TE/c=; b=blY2mMKSnqQvQxpBEdINI+H1p6J/FC0f69CgofLT6B9H5ymBaE14uBXqdh5wMgd7rU VBiXMLxRpmo+CZZIt/iLhkWCQDOfR02+pckEwPF9k749ZoLBtvB1Qm7HcyKGewHg8J2m M3O9k0qbvf6Tkagk3OVSj6VAWg5UwCdQDFpftmdWQf25VEN7Neqd8dVOjVUBIPh+QBhL ULqgzIw7yxuk2WyxFmSkfY2FU+xc7LoMJ1zofsDUUTaQARgIwuU0d91M6c0A5bUNQ5Vj EwT6PtpJaT89dRXTLiq5CR7wiKHaQsFjf9Ge2OM2P8jtpwEjUSsnTY+Iu3e+q16U5r51 k0ag== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio0dVVInWnas+zpAhAiA/W" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.19.0 DYNA|AUTH) with ESMTPSA id w0550ex1JNeT1LQ (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sat, 20 Feb 2021 00:40:29 +0100 (CET) Received: from rolf-aux.obsigna.com (rolf-aux.obsigna.com [192.168.222.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id A33F21350F946; Fri, 19 Feb 2021 20:40:24 -0300 (-03) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Subject: Re: LLDB on FreeBSD/arm64 and arm From: "Dr. Rolf Jansen" In-Reply-To: Date: Fri, 19 Feb 2021 20:40:23 -0300 Cc: freebsd-arm , Ed Maste Content-Transfer-Encoding: quoted-printable Message-Id: References: <9EDAF212-EA86-4AAC-97C6-BB801161DC4D@obsigna.com> <6FAC63F4-79D8-4D25-BC29-44371303A09B@obsigna.com> To: =?utf-8?B?TWljaGHFgiBHw7Nybnk=?= X-Mailer: Apple Mail (2.3445.9.7) X-Rspamd-Queue-Id: 4Dj7P71NLqz3n9X X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obsigna.com header.s=strato-dkim-0002 header.b=blY2mMKS; arc=pass (strato.com:s=strato-dkim-0002:i=1); dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@obsigna.com designates 85.215.255.25 as permitted sender) smtp.mailfrom=freebsd-rj@obsigna.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[85.215.255.25:from]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[obsigna.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[85.215.255.25:from]; ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_ALLOW(-1.00)[strato.com:s=strato-dkim-0002:i=1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[obsigna.com:s=strato-dkim-0002]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[obsigna.com]; SPAMHAUS_ZRD(0.00)[85.215.255.25:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[85.215.255.25:from]; FROM_NAME_HAS_TITLE(1.00)[dr]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Porting FreeBSD to ARM processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 23:40:44 -0000 Am 17.02.2021 um 13:34 schrieb Micha=C5=82 G=C3=B3rny = : > On Wed, 2021-02-17 at 12:21 -0300, Dr. Rolf Jansen wrote: >> Am 16.02.2021 um 11:01 schrieb Michal Meloun >: >>> On 16.02.2021 14:34, Dr. Rolf Jansen wrote: >>>> Am 05.02.2021 um 13:40 schrieb Micha=C5=82 G=C3=B3rny = : >>>>> On Fri, 2021-02-05 at 12:30 -0300, Dr. Rolf Jansen wrote: >>>>>> Am 03.02.2021 um 14:53 schrieb Ed Maste : >>>>>>=20 >>>>>>> As you may know, the FreeBSD Foundation sponsored Moritz Systems = to >>>>>>> improve LLDB's support of non-x86 FreeBSD targets (and some = other >>>>>>> improvements applicable to all targets). This builds on their >>>>>>> earlier >>>>>>> work to update x86 support. >>>>>>>=20 >>>>>>> Initial changes for arm64 and arm support were recently = committed >>>>>>> upstream. Details are in these code reviews, if you're = interested: >>>>>>>=20 >>>>>>> https://reviews.llvm.org/D95297 (arm64) >>>>>>> https://reviews.llvm.org/D95696 (arm) >>>>>>>=20 >>>>>>> arm and arm64 users with an interest in LLDB are encouraged to = build >>>>>>> LLDB from the upstream git repository, try out the support, and >>>>>>> report >>>>>>> issues or positive results. >>>>>>>=20 >>>>>>> It should build using the regular build process as described at >>>>>>> https://lldb.llvm.org/resources/build.html >>>>>>>=20 >>>>>>> At present all four of 32- and 64-bit arm and x86 use LLDB's >>>>>>> non-legacy debug support by default. Legacy support will be = removed >>>>>>> from LLDB upon completion of Moritz' work (once all = architectures >>>>>>> are >>>>>>> patched) and there is no need to try out legacy support. >>>>>>=20 >>>>>> I am interested to build LLDB from the upstream repository. As a >>>>>> matter of fact a few years ago I did this already directly on a >>>>>> BeagleBone Black, however in the meantime the LLVM sources had = grown >>>>>> beyond the capacity a BBB could compile. Already at that time a = rather >>>>>> limited build took more than 48 hs. >>>>>>=20 >>>>>> I set up an ARMv7 cross building environment for kernel and world = on a >>>>>> reasonably equipped i7 machine. Can I somehow use this for = building >>>>>> LLDB as well? >>>>>=20 >>>>> Yes. See our summary for some tips: >>>>>=20 >>>>> = https://www.moritz.systems/blog/freebsd-remote-process-plugin-on-non-x86-a= rchitectures/ >>>>>=20 >>>>> Go for 'Cross-compiling LLVM'. On ARMv7, you'll have to change >>>>> the target and host triplets to = armv7-unknown-freebsd13.0-gnueabihf >>>>> and LLVM target to ARM. >>>>>=20 >>>>>> I provided ssh root access to one of my BBBs to Micha=C5=82 = G=C3=B3rny for >>>>>> testing his work, and he left a LLDB on the system, I don't know = at >>>>>> which stage, though. When debugging an advanced project of mine = with >>>>>> this one I see some show stoppers (as with the original LLDB). >>>>>> Perhaps, I could be of help to improve LLDB. >>>>>=20 >>>>> If it's about watchpoints, then we need to support them on kernel = level >>>>> first. For anything else, we need to figure out what's = wrong/missing. >>>> It took a while until I got it working - =E2=80=9Etoo many = variables, so few time=E2=80=9C >>>> In the toolchains file, I needed to add a definition for sysroot. = When passing it with the C_FLAGS and CXX_FLAGS, I got typical 32 vs. 64 = bit errors very early in the build process. Something like size_t is not = long. The working toolchain file for ARMv7 is the following =E2=80=94 = is the placeholder for the actual path, here it is = /root/install/BBB/sysroot: >>>> set(CMAKE_C_FLAGS "-target armv7-unknown-freebsd13.0-gnueabihf") >>>> set(CMAKE_CXX_FLAGS "-target = armv7-unknown-freebsd13.0-gnueabihf") >>>> set(CMAKE_SYSROOT ) >>>> set(CMAKE_SYSTEM_NAME "FreeBSD") >>>> set(CMAKE_FIND_ROOT_PATH ) >>>> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) >>>> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) >>>> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) >>>> Before, I found this out, I meandered between versions of LLVM (I = compiled 10.x, 11.x, 12.x and HEAD), and I switched to another build = machine, before it was FreeBSD 12.2-RELEASE on a real i7 and now I build = in a VM running FreeBSD 13.0-BETA2. However, without the definition of = CMAKE_SYSROOT all this did not work out. >>>> Now I deployed a lldb to my BeagleBone running 13-BETA2 as well: >>>> lldb version 13.0.0 (https://github.com/llvm/llvm-project.git = revision b40fde062c306584d88243de11175187e754ce3b) >>>> clang revision b40fde062c306584d88243de11175187e754ce3b >>>> llvm revision b40fde062c306584d88243de11175187e754ce3b >>>> I am able to debug simple programs, but the happiness ends already = when trying to enter a subroutine. At least this worked well with lldb = 11.0.1, which has been build by using in the course of world by = WORLD_FLAGS=3D"MK_LLDB=3Dyes=E2=80=9C. However both bail out, when I try = to debug a bigger project of mine. >>>> (lldb) target create "./CyDaemon" >>>> Current executable set to '/root/install/CyDaemon/CyDaemon' (arm). >>>> (lldb) settings set -- target.run-args "-f" "-l" "80" "-s" "443" >>>> (lldb) r >>>> Process 767 launched: '/root/install/CyDaemon/CyDaemon' (arm) >>>> Process 767 stopped >>>> * thread #1, name =3D 'CyDaemon', stop reason =3D signal SIGILL: = illegal instruction >>>> frame #0: 0x20290048 >>>> -> 0x20290048: vmull.p64 q0, d0, d0 >>>> 0x2029004c: bx lr >>>> 0x20290050: ldr r0, [pc, #0x68] >>>> 0x20290054: add r1, pc, #100 >>>> (lldb) >>>> The question now is, how to continue from here? Do we continue? If = yes, do we build on FreeBSD 13.0-RELEASE (BETAx for some more days) or = do we build on 14-CURRENT? Which version of lldb do we debug? A release = version or HEAD? >>>> The last lldb which worked absolutely well on the BBB was 3.9 or = was it 4.x. I know, that I never got 5.x to compile on the BBB. However = now, that my cross-building environment has been set up, I probably will = check that as well. >>>> Best regards >>>> Rolf >>>=20 >>> Hi Rolf, >>> This is quite normal behavior.. Your program uses crypt library ant = this library determines presence of crypto extension instructions = (Cortex A9 have not these). The library have SIGILL signal handler = installed and if vmull instruction is not supported it switches to pure = sw mode. In this case do nothing else press continue... >>=20 >> OK, this make sense. Actually, I need to continue 5 times. Now I pass = a startup script file on the lldb command line so it skips this = annoyance automatically: >>=20 >> -s lldbstartup >>=20 >> run >> process handle -n false -p true -s false SIGILL >> continue >>=20 >> I now compiled release/11.x and this works well, except the = longstanding issue, by which lldb in the GUI loses the focus when = stepping through a threaded program =E2=80=94 see = https://lists.llvm.org/pipermail/lldb-dev/2017-November/012954.html = >>=20 >> Anyhow, this thread is about testing new features which made it into = LLDB for FreeBSD arm[64|], and my question remains, where did these = additions landed (main?, release/12.x?, release/11.x?) and what would I = test? >=20 > I'm sorry for not replying earlier. The newest LLDB work is only > available on main branch of llvm-project at the moment (12.0.0 RCs = were > already underway when we started). For most of the features any = recent > FreeBSD is fine (12-ish) but arm64 watchpoint support was just pushed = to > main. So, I am stuck with release/11.x, since compiling release/12.x errors = out and main does compile but with that I can only step into subroutines = in very simple code, however, when I use it with real world programs it = hangs when stepping in or over any subroutine call. For the time being, = I will stop these efforts. Best regards. Rolf=