From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1427723AbdDWG6I (ORCPT ); Sun, 23 Apr 2017 02:58:08 -0400 Received: from conssluserg-04.nifty.com ([210.131.2.83]:34824 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1427654AbdDWG55 (ORCPT ); Sun, 23 Apr 2017 02:57:57 -0400 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com v3N6von3021680 X-Nifty-SrcIP: [209.85.213.174] MIME-Version: 1.0 In-Reply-To: <20170421195502.GL128305@google.com> References: <20170404172706.171971-1-mka@chromium.org> <20170421195502.GL128305@google.com> From: Masahiro Yamada Date: Sun, 23 Apr 2017 15:57:49 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] kbuild: Add support to generate LLVM bitcode files To: Matthias Kaehlcke Cc: Michal Marek , Emese Revfy , Kees Cook , Behan Webster , "Luis R . Rodriguez" , =?UTF-8?Q?Vin=C3=ADcius_Tinti?= , Kyeongmin Cho , Linux Kernel Mailing List , Linux Kbuild mailing list , Grant Grundler , Michael Davidson , Greg Hackmann , Peter Foley Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v3N6wAF7017682 Hi Matthias, 2017-04-22 4:55 GMT+09:00 Matthias Kaehlcke : > Hi Masahiro, > > El Fri, Apr 21, 2017 at 02:02:46PM +0900 Masahiro Yamada ha dit: > >> 2017-04-05 2:27 GMT+09:00 Matthias Kaehlcke : >> > From: Vinícius Tinti >> > >> > Add rules to kbuild in order to generate LLVM bitcode files with the .ll >> > extension when using clang. >> >> >> First, I'd like to be sure about the terminology "LLVM bitcode" >> because "bitcode" sounds like human-unreadable binary. >> >> >> For example, 'man llvm-as' says: >> llvm-as is the LLVM assembler. It reads a file containing >> human-readable LLVM assembly language, translates it to LLVM >> bitcode, and writes the result into a file or to standard output. >> >> >> As far as I understood: >> >> *.ll - LLVM assembly (human readable file) >> *.bc - LLVM bitcode (binary file) >> >> Is this correct? > > Yes, the terminology should be changed to talk about 'LLVM assembly'. > >> > # from c code >> > CC=clang make kernel/pid.ll >> >> This does not work because CC is overridden in the top-level Makefile. >> It should be >> make CC=clang kernel/pid.ll > > Will change > >> > # from asm code >> > CC=clang make arch/x86/kernel/preempt.ll >> >> arch/x86/kernel/preempt.* does not exist >> (at least in the latest tree). >> >> >> >> >> > + >> > +quiet_cmd_as_ll_S = CPP $(quiet_modtag) $@ >> > + cmd_as_ll_S = $(CPP) $(a_flags) -o $@ $< >> > + >> > +$(obj)/%.ll: $(src)/%.S FORCE >> > + $(call if_changed_dep,as_ll_S) >> > + >> >> I could not understand how this rule can convert >> architecture-specific assembly to LLVM intermediate expression. >> >> This is just pre-processing *.S file. >> >> >> Actually, this is completely the same as the rule *.S -> *.s >> >> quiet_cmd_cpp_s_S = CPP $(quiet_modtag) $@ >> cmd_cpp_s_S = $(CPP) $(a_flags) -o $@ $< >> >> $(obj)/%.s: $(src)/%.S FORCE >> $(call if_changed_dep,cpp_s_S) > > Indeed, unsurprisingly the content of a .ll file generated from a .S > is the same as the corresponding .s. > > Besides the Makefile rules it isn't clear to me how assembly would be > converted to LLVM IR. I suggest to remove the rules for assembly. > I agree. This rule should be removed. -- Best Regards Masahiro Yamada