From owner-freebsd-arm@FreeBSD.ORG Fri Jun 13 20:30:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC70E40F; Fri, 13 Jun 2014 20:30:41 +0000 (UTC) Received: from forward9l.mail.yandex.net (forward9l.mail.yandex.net [IPv6:2a02:6b8:0:1819::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Certum Level IV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EA152394; Fri, 13 Jun 2014 20:30:40 +0000 (UTC) Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward9l.mail.yandex.net (Yandex) with ESMTP id 1E85FE61A41; Sat, 14 Jun 2014 00:30:36 +0400 (MSK) Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id A69451B608CC; Sat, 14 Jun 2014 00:30:35 +0400 (MSK) Received: from unknown (unknown [12.202.173.169]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id DKYOAxpOvw-UYjOehN2; Sat, 14 Jun 2014 00:30:35 +0400 (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: fe3262db-bab6-46e1-b5fb-3f081a197680 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=narod.ru; s=mail; t=1402691435; bh=uPisSmMUZyBrhKYu1rJlLyMm+zyeI2d8MlpShfi1UZE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gS5Ec6NK3E52tdDq7MlsLTtXoeDzjsGZ+V1hfGIF/7XuSP8TGWLrryjDg7xSkffjz NpgJ+D77ueU3aPi+IqDm6jD4o6TR/AtWkR0hbH83P/rv5UYTxQOH4uoEbyt44tFpIk ObUGiLepdHXvkx34Z3p0aQR0qVtN7Ayi+I1P8XpE= Authentication-Results: smtp8.mail.yandex.net; dkim=pass header.i=@narod.ru Message-ID: <539B5F68.5020008@narod.ru> Date: Sat, 14 Jun 2014 02:30:32 +0600 From: Stepan Dyatkovskiy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Compilation for ARM References: <53935D02.2030604@narod.ru> <6D7645D2-9C08-4B5D-BAA5-5B6EC8F66F0B@kientzle.com> <5393FF7B.4020407@narod.ru> <1402428857.20883.177.camel@revolution.hippie.lan> <5398B1A2.3010007@narod.ru> <1402591005.20883.213.camel@revolution.hippie.lan> <539A2261.4070705@narod.ru> <539A62E2.20003@narod.ru> <1402676121.20883.231.camel@revolution.hippie.lan> <539B24DB.4090005@narod.ru> <1402677258.20883.235.camel@revolution.hippie.lan> In-Reply-To: <1402677258.20883.235.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 20:30:41 -0000 Modern compilers forbid to use nested .fnstart constructions (actually nested ENTRY uses). But FreeBSD code has them in few places. For example, in arm/exception.S file (see swi_entry). I saw the comment nearby swi_exit definition, but now quite understand how it relates with nested ENTRY uses... It looks like several entries were intruduced just because of alternative names for the same function. But I'm not sure... Thanks! -Stepan Why we need them Ian Lepore wrote: > On Fri, 2014-06-13 at 22:20 +0600, Stepan Dyatkovskiy wrote: >> Hi Ian, >> Yup. I have done it with default options. That works fine. Thanks! >> >> But, currently we need to compare launch times for kernel that was >> compiled with cortex-a9 options and for kernel that was compiled with >> cortex-a15 options. >> >> The reason of doing that is some improvements in clang backend that >> promises faster execution for (-mcpu=cortex-a15). So we would like to >> check it on FreeBSD kernel, since we going to use this OS as base for >> our applications. >> >> -Stepan > > I wonder if it is upset that the nesting is backwards, like > > NP_ENTRY(btext) > ASENTRY_NP(_start) > ... > END(btext) > END(_start) > > Maybe try switching the order of the END macros? If that doesn't help, > try removing the btext macros completely, I don't think they're needed > by anything these days. > > -- Ian > >