From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DD08C4361B for ; Tue, 15 Dec 2020 09:02:48 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0FF9322225 for ; Tue, 15 Dec 2020 09:02:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0FF9322225 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.52983.92451 (Exim 4.92) (envelope-from ) id 1kp6E1-00020I-63; Tue, 15 Dec 2020 09:02:29 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 52983.92451; Tue, 15 Dec 2020 09:02:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kp6E1-00020B-2X; Tue, 15 Dec 2020 09:02:29 +0000 Received: by outflank-mailman (input) for mailman id 52983; Tue, 15 Dec 2020 09:02:28 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kp6Dz-000206-Tt for xen-devel@lists.xenproject.org; Tue, 15 Dec 2020 09:02:27 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 1142cad0-147c-4da7-8e4b-719e062fa78a; Tue, 15 Dec 2020 09:02:26 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id D0A88ACC6; Tue, 15 Dec 2020 09:02:25 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 1142cad0-147c-4da7-8e4b-719e062fa78a X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1608022946; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bAmMwBy6AtYV+lM/clxgOraoypqXS/jSPLvVclLrz+Y=; b=nbnw1fETW4MN2c2OKoXOOFmuOBn4MmZlBrLrcs4r10WJ/tSvY67Aai702Bnf1lViczM/tT lQu0doBiBl3VSgudnZXpQZD36+IBL4jK6Y0pssbHdQFwflZEOIRNbi6JeYdfj9Vr8isWM9 p7UpUh5q0Uhl822nsRHSq8yk42DwJ0M= Subject: Re: [PATCH v5 1/3] xen/arm: add support for run_in_exception_handler() To: Juergen Gross Cc: Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Ian Jackson , Wei Liu , xen-devel@lists.xenproject.org References: <20201215063319.23290-1-jgross@suse.com> <20201215063319.23290-2-jgross@suse.com> From: Jan Beulich Message-ID: <94e85d88-b0f0-01f6-99e0-386326bc044a@suse.com> Date: Tue, 15 Dec 2020 10:02:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20201215063319.23290-2-jgross@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 15.12.2020 07:33, Juergen Gross wrote: > --- a/xen/include/asm-arm/bug.h > +++ b/xen/include/asm-arm/bug.h > @@ -15,65 +15,62 @@ > > struct bug_frame { > signed int loc_disp; /* Relative address to the bug address */ > - signed int file_disp; /* Relative address to the filename */ > + signed int ptr_disp; /* Relative address to the filename or function */ > signed int msg_disp; /* Relative address to the predicate (for ASSERT) */ > uint16_t line; /* Line number */ > uint32_t pad0:16; /* Padding for 8-bytes align */ > }; > > #define bug_loc(b) ((const void *)(b) + (b)->loc_disp) > -#define bug_file(b) ((const void *)(b) + (b)->file_disp); > +#define bug_ptr(b) ((const void *)(b) + (b)->ptr_disp); > #define bug_line(b) ((b)->line) > #define bug_msg(b) ((const char *)(b) + (b)->msg_disp) > > -#define BUGFRAME_warn 0 > -#define BUGFRAME_bug 1 > -#define BUGFRAME_assert 2 > +#define BUGFRAME_run_fn 0 > +#define BUGFRAME_warn 1 > +#define BUGFRAME_bug 2 > +#define BUGFRAME_assert 3 > > -#define BUGFRAME_NR 3 > +#define BUGFRAME_NR 4 > > /* Many versions of GCC doesn't support the asm %c parameter which would > * be preferable to this unpleasantness. We use mergeable string > * sections to avoid multiple copies of the string appearing in the > * Xen image. > */ > -#define BUG_FRAME(type, line, file, has_msg, msg) do { \ > +#define BUG_FRAME(type, line, ptr, msg) do { \ > BUILD_BUG_ON((line) >> 16); \ > BUILD_BUG_ON((type) >= BUGFRAME_NR); \ > asm ("1:"BUG_INSTR"\n" \ > - ".pushsection .rodata.str, \"aMS\", %progbits, 1\n" \ > - "2:\t.asciz " __stringify(file) "\n" \ > - "3:\n" \ > - ".if " #has_msg "\n" \ > - "\t.asciz " #msg "\n" \ > - ".endif\n" \ > - ".popsection\n" \ > - ".pushsection .bug_frames." __stringify(type) ", \"a\", %progbits\n"\ > - "4:\n" \ > + ".pushsection .bug_frames." __stringify(type) ", \"a\", %%progbits\n"\ > + "2:\n" \ > ".p2align 2\n" \ > - ".long (1b - 4b)\n" \ > - ".long (2b - 4b)\n" \ > - ".long (3b - 4b)\n" \ > + ".long (1b - 2b)\n" \ > + ".long (%0 - 2b)\n" \ > + ".long (%1 - 2b)\n" \ > ".hword " __stringify(line) ", 0\n" \ > - ".popsection"); \ > + ".popsection" :: "i" (ptr), "i" (msg)); \ > } while (0) The comment ahead of the construct now looks to be at best stale, if not entirely pointless. The reference to %c looks quite strange here to me anyway - I can only guess it appeared here because on x86 one has to use %c to output constants as operands for .long and alike, and this was then tried to use on Arm as well without there really being a need. Jan