From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=izi7274L; spf=pass (domain: linaro.org, ip: 209.85.128.65, mailfrom: leif.lindholm@linaro.org) Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by groups.io with SMTP; Thu, 19 Sep 2019 07:31:58 -0700 Received: by mail-wm1-f65.google.com with SMTP id i16so4832182wmd.3 for ; Thu, 19 Sep 2019 07:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=F8LqqGbxuOSLcC4pgNt99V92E1jwsS81iYCIDTaYjfU=; b=izi7274LtdhkVGPBRTkbGC5nhFGrXhFivLMZ6iA9D+U7eA0W2BkPjXGmJoWKcE2fhA 4ikxQsZ3WvrjCdkF8RNtYM9ZqcyTiPrvet7YJ9NMAOuzu8zmS8Jdbz4gAXO68WwKcuid mvV+ZsNcHRqyKMcsladlGUvEbysGPtLEv5IGcFs46id/dEAMZgmNkMjP22XxaO0EO7XA QvDAA1NgmbFAPfPVVfrkZb4L1d4DLYpL8xngXShoR5ecV1EBPKmLRABLzOsqbaKcZ9j/ l96aNpNvG5biPbgvYY8YG8O4HouC6IUHS5UujtGImTNfDU7V7qIaAfQgRNTM98Ol8UBR aOog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=F8LqqGbxuOSLcC4pgNt99V92E1jwsS81iYCIDTaYjfU=; b=Evc3Yc/wHvn+95Lb5Ka+Em88i8oplcG4yrr50Pgs0sWScnnokxjNa+Eo+O6ub7Hzok pr0w1mvjWbOh6FC/bjmI49atYzkGYoZl2r6pEsyjto36Mz/AozxJwfYgCRNKTe/0a59v Lxa32JVYidr63p+dBYBUWQ2lMAFI8HOlKvpXGKVk0tJl3rqTfMfXiKipPPfoPxrQMu0b RztV1EEBtIKNf0WZna0oJEa+yGVDwXy1w16Kv9bhawqKWJeR2OP8dqxupK7mQdVB3bYT NDrdty0o+sdrXf+XLwU9kZEevcmbYY1FQ+3H0okWeicjP5s3u4XB8m2DzZXO3/0yug+B s0sA== X-Gm-Message-State: APjAAAWGx5akRItP53Lk5tcunhu8mPAyJnRO9K1JwK1UoW67m6Vx3Sxc QlF8Ea07OzY0ra6gw+yu9a6Wgw== X-Google-Smtp-Source: APXvYqzks3YcGU7/+ih6n0q5spqCaYzPkGX/oiRQL0S9EuKsVtOzm8S8pJXa/kAsuJ67qa61CE2tnw== X-Received: by 2002:a7b:ce91:: with SMTP id q17mr3108040wmj.25.1568903517008; Thu, 19 Sep 2019 07:31:57 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id o9sm14410933wrh.46.2019.09.19.07.31.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Sep 2019 07:31:56 -0700 (PDT) Date: Thu, 19 Sep 2019 15:31:54 +0100 From: "Leif Lindholm" To: Ard Biesheuvel Cc: Baptiste Gerondeau , edk2-devel-groups-io , "Kinney, Michael D" , "Gao, Liming" , "Zhang, Shenglei" , Baptiste GERONDEAU Subject: Re: [PATCH 2/3] ARM/Assembler: Correct syntax from RVCT for MSFT Message-ID: <20190919143154.GX28454@bivouac.eciton.net> References: <20190919094846.GO28454@bivouac.eciton.net> <20190919100921.GR28454@bivouac.eciton.net> <20190919104711.GT28454@bivouac.eciton.net> <20190919112531.GU28454@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 19, 2019 at 03:36:50PM +0300, Ard Biesheuvel wrote: > On Thu, 19 Sep 2019 at 14:25, Leif Lindholm wrote: > > > The problem is that the first branch instruction is patched into the > > > FV files by the BaseTools, and so the startup code is entered in ARM > > > mode by default. > > > > > > So that means we'll either have to > > > 1) switch to ARM mode > > > 2) emit one branch instruction > > > 3) switch back to Thumb mode > > > > I was thinking more like tying down the entry function (or as I said, > > the whole file) as ARM, then letting the toolchain decide for the bits > > where we don't have instuction-set dependent ABIs. > > > > > 4) fix up all the code so it assembles in Thumb mode > > > > Which is what Baptiste has done in this set. > > > > > 1) switch to ARM mode > > > > In all 48 files (+3 in edk2-platforms), or just the ones where not > > doing so triggers build errors? Currently. > > > > I'm OK with restricting ourselves to just setting ARM in the > > triggering files for simplicity, especially in order to streamline the > > toolchain migration from RVCT to VS (and the subsequent purge of PVCT > > support). I'm not seeing it as a solution. > > As long as we align the .asm files with the .S files, I am fine with > that. And since we focus on v7+ only these days, I'm fine with > changing existing ARM files to Thumb2. But I don't see us following this pattern today, for .S files. Frankly, looking at it, I can't quite manage to untangle how we end up generating A32 for .asm in the first place. Is it just the toolchain default? If we look for example at the post-build version of Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/ArmHvcLib/ArmHvcLib/OUTPUT/Arm/ArmHvc.iii , there is no .arm directive. That gets assembled into Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/ArmHvcLib/ArmHvcLib/OUTPUT/Arm/ArmHvc.obj by the step --- "arm-linux-gnueabihf-gcc" -march=armv7-a -c -x assembler -imacros /work/git/tianocore/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/ArmHvcLib/ArmHvcLib/DEBUG/AutoGen.h -mlittle-endian -o /work/git/tianocore/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/ArmHvcLib/ArmHvcLib/OUTPUT/Arm/ArmHvc.obj -I/work/git/edk2/ArmPkg/Library/ArmHvcLib/Arm -I/work/git/edk2/ArmPkg/Library/ArmHvcLib -I/work/git/tianocore/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/ArmHvcLib/ArmHvcLib/DEBUG -I/work/git/edk2/MdePkg -I/work/git/edk2/MdePkg/Include -I/work/git/edk2/MdePkg/Include/Arm -I/work/git/edk2/ArmPkg -I/work/git/edk2/ArmPkg/Include /work/git/tianocore/Build/ArmVirtQemu-ARM/RELEASE_GCC5/ARM/ArmPkg/Library/ArmHvcLib/ArmHvcLib/OUTPUT/Arm/ArmHvc.iii --- (Adding hilarity to the situation is the bit where we, when preprocessing the file, explicitly pass -mthumb on the command line - which is obviously ignored at that point.) Fwiw, yes, it appears at least the Debian toolchain defaults to assembling A32 if no .thumb directive is explicitly in place. > What I don't want is a situation where the toolchain's default decides > how code is assembled, since that means you have to test all your code > changes twice. And to me it looks like we avoid that problem today only by accident - we are already relying on toolchain defaults for GCC. Anyway, rewinding this about 27 steps ... Are you OK with Baptiste going ahead and adding the ARM statement *only* to the files requiring it to build[1] - and the one(s) requiring it to operate properly (could you point it/them out please)? [1] Then the next question is whether he should also add it to the files where that avoids the need for (some) refactoring of code, or whether he should simply mirror the changes to .asm into .S? The "we must tie down so that each .asm/.S file is only ever built to a single instruction set" work is a substantial enough task, that I hope we can undertake at a later date rather that rolling it into this one. / Leif