Date: Sun, 22 Jun 2014 04:56:33 -0700 From: falcon17@hushmail.com To: freebsd-arm@freebsd.org Subject: build world cross compile Message-ID: <20140622115633.E847320185@smtp.hushmail.com>
index | next in thread | raw e-mail
I would like to build 10-STABLE for arm on my amd64. I found some instructions here -https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD(i assume the third CPUTYPE example should be KERNCONF instead?) all looks good, except that make.conf and src.conf examples do not say a peep about arm! What are the right way of specifying these targets? Do I need to build a special compiler before starting? Thanks! From owner-freebsd-arm@FreeBSD.ORG Sun Jun 22 15:53:30 2014 Return-Path: <owner-freebsd-arm@FreeBSD.ORG> Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9F005B6 for <arm@FreeBSD.org>; Sun, 22 Jun 2014 15:53:30 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 855AF203B for <arm@FreeBSD.org>; Sun, 22 Jun 2014 15:53:30 +0000 (UTC) Received: from bender.lan (97e07ba1.skybroadband.com [151.224.123.161]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 852A05DEC1; Sun, 22 Jun 2014 15:53:28 +0000 (UTC) Date: Sun, 22 Jun 2014 16:53:21 +0100 From: Andrew Turner <andrew@fubar.geek.nz> To: John-Mark Gurney <jmg@funkthat.com> Subject: Re: AVILA getting close! Message-ID: <20140622165321.04c0949a@bender.lan> In-Reply-To: <20140622051644.GT31367@funkthat.com> References: <20140618225808.GG31367@funkthat.com> <20140620151023.GZ31367@funkthat.com> <20140620200827.1c33c7da@bender.Home> <20140621010804.GD31367@funkthat.com> <20140621070827.GJ31367@funkthat.com> <20140621170129.76e62c27@bender.Home> <20140622051644.GT31367@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sun, 22 Jun 2014 15:53:30 -0000 On Sat, 21 Jun 2014 22:16:44 -0700 John-Mark Gurney <jmg@funkthat.com> wrote: > Andrew Turner wrote this message on Sat, Jun 21, 2014 at 17:01 +0100: > > On Sat, 21 Jun 2014 00:08:28 -0700 > > John-Mark Gurney <jmg@funkthat.com> wrote: > > > I've looked at the assembly for donelist_init for both the working > > > and non-working case, and besides an extra store in the good > > > version, which I think is just because of the unoptimized code, > > > things look the same to me... > > I suspect it's more likely the working version is not making > > assumptions on the stack alignment, where the broken one is. > > So, is there a way you can fix up the rtld tramp in > rtld-elf/arm/rtld_start.S so that the stack can be traced through? > > Right now, when I'm in the plt code, I can get the userland stack, > but once I end up in _rtld_bind_start, I can't get a trace back > past the got which is making this next to imposible to debug.. > > (gdb) stepi > 0x200774d4 in .plt () from /lib/libc.so.7 > 2: $pc = 0x200774d4 > 1: $sp = 0xbffff24c > (gdb) bt > #0 0x200774d4 in .plt () from /lib/libc.so.7 > #1 0x20171804 in getenv (name=0x20184a98 "MALLOC_CONF") > at /usr/src.avila/lib/libc/stdlib/getenv.c:144 > #2 0x200f23b0 in malloc_init_hard () at jemalloc_jemalloc.c:464 > #3 0x200f34d8 in jemalloc_constructor () at jemalloc_jemalloc.c:296 > #4 0x2001dee0 in objlist_call_init (list=<value optimized out>, > lockstate=0xbffffb40) > at /usr/src.avila/libexec/rtld-elf/rtld.c:2385 #5 0x200212b8 in $a > () at /usr/src.avila/libexec/rtld-elf/rtld.c:640 #6 0x200212b8 in $a > () at /usr/src.avila/libexec/rtld-elf/rtld.c:640 (gdb) stepi > _rtld_bind_start () > at /usr/src.avila/libexec/rtld-elf/arm/rtld_start.S:80 > 80 stmdb sp!,{r0-r4,sl,fp} 2: $pc = 0x20018f84 > 1: $sp = 0xbffff24c > Current language: auto; currently asm > (gdb) bt > #0 _rtld_bind_start () > at /usr/src.avila/libexec/rtld-elf/arm/rtld_start.S:80 #1 0x2019e0c0 > in .got () from /lib/libc.so.7 #2 0x2019e0c0 in .got () > from /lib/libc.so.7 > > Poof, now I have no clue where I am anymore... :( Or at least > provide an option (enabled by -DDEBUG) to provide it.. > > Well, I did manage to work this out.. and I feel a little stupid since > I saw this name and thought it a bit weird.. I believe that gcc is > is not making sure that the stack is aligned when calling > __aeabi_read_tp... I believe that gcc does not think that it is a > full function, but it does go through relocation... If you look at the > disassembly of the sob function in newsyslog, you'll see that it will > leave the stack unaligned off the bat: > 9f58: e92d4030 push {r4, r5, lr} > > and setting a breakpoint there confirms this: > (gdb) c > Continuing. > > Breakpoint 8, sob ( > p=0xbfffef20 "/var/log/all.log\t\t\t600 7\t *\t@T00 J\n") > at /usr/src.avila/usr.sbin/newsyslog/newsyslog.c:2400 > 2400 while (p && *p && isspace(*p)) > 2: $pc = 0x9f5c > 1: $sp = 0xbfffeeec > > So, gcc is generating broken code... Can you please fix this? > > Thanks. > We tracked this down to a problem where, normally the stack is aligned to an 8-byte boundary, however in leaf functions the stack may be aligned to a 4-byte boundary. The problem is gcc and upstream clang/llvm don't detect that functions that use thread local storage as non-leaf. Functions that use tls call __aeabi_read_tp(). As this is implemented in libc it requires the symbol to be resolved first, however as the compiler doesn't see this as a function call it may align the stack to a non-8-byte address. I have a fix for this that has been tested on armeb. I'll commit it soon, after I've tested it on other platforms. Andrewhelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140622115633.E847320185>