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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 480C1C433E0 for ; Sat, 6 Feb 2021 16:26:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0BBC1614A7 for ; Sat, 6 Feb 2021 16:26:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229988AbhBFQ0L (ORCPT ); Sat, 6 Feb 2021 11:26:11 -0500 Received: from wildebeest.demon.nl ([212.238.236.112]:47000 "EHLO gnu.wildebeest.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbhBFQ0K (ORCPT ); Sat, 6 Feb 2021 11:26:10 -0500 Received: from librem (deer0x15.wildebeest.org [172.31.17.151]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 4216A30278CD; Sat, 6 Feb 2021 17:25:28 +0100 (CET) Received: by librem (Postfix, from userid 1000) id BD303C100B; Sat, 6 Feb 2021 17:24:19 +0100 (CET) Date: Sat, 6 Feb 2021 17:24:19 +0100 From: Mark Wieelard To: Yonghong Song Cc: sedat.dilek@gmail.com, Masahiro Yamada , Arnaldo Carvalho de Melo , Arnaldo Carvalho de Melo , dwarves@vger.kernel.org, Linux Kernel Mailing List , bpf@vger.kernel.org, Jiri Olsa , Jan Engelhardt , Domenico Andreoli , Matthias Schwarzott , Andrii Nakryiko , Paul Moore , Ondrej Mosnacek , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Tom Stellard Subject: Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type Message-ID: <20210206162419.GC2851@wildebeest.org> References: <20210205192446.GH920417@kernel.org> <8ff11fa8-46cd-5f20-b988-20e65e122507@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ff11fa8-46cd-5f20-b988-20e65e122507@fb.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: dwarves@vger.kernel.org Hi, On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote: > With the above vmlinux, the issue appears to be handling > DW_ATE_signed_1, DW_ATE_unsigned_{1,24,40}. > > The following patch should fix the issue: That doesn't really make sense to me. Why is the compiler emitting a DW_TAG_base_type that needs to be interpreted according to the DW_AT_name attribute? If the issue is that the size of the base type cannot be expressed in bytes then the DWARF spec provides the following option: If the value of an object of the given type does not fully occupy the storage described by a byte size attribute, the base type entry may also have a DW_AT_bit_size and a DW_AT_data_bit_offset attribute, both of whose values are integer constant values (see Section 2.19 on page 55). The bit size attribute describes the actual size in bits used to represent values of the given type. The data bit offset attribute is the offset in bits from the beginning of the containing storage to the beginning of the value. Bits that are part of the offset are padding. If this attribute is omitted a default data bit offset of zero is assumed. Would it be possible to use that encoding of those special types? If not, can we try to come up with some extension that doesn't require consumers to match magic names? Thanks, Mark