lkml.org 
[lkml]   [2021]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
    On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song <yhs@fb.com> wrote:
    >
    >
    >
    > On 2/6/21 8:24 AM, Mark Wieelard wrote:
    > > 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
    >
    > I agree with you. I do not like comparing me as well. Unfortunately,
    > there is no enough information in dwarf to find out actual information.
    > The following is the dwarf dump with vmlinux (Sedat provided) for
    > DW_ATE_unsigned_1.
    >
    > 0x000e97e9: DW_TAG_base_type
    > DW_AT_name ("DW_ATE_unsigned_1")
    > DW_AT_encoding (DW_ATE_unsigned)
    > DW_AT_byte_size (0x00)
    >
    > There is no DW_AT_bit_size and DW_AT_bit_offset for base type.
    > AFAIK, these two attributes typically appear in struct/union members
    > together with DW_AT_byte_size.
    >
    > Maybe compilers (clang in this case) can emit DW_AT_bit_size = 1
    > and DW_AT_bit_offset = 0/7 (depending on big/little endian) and
    > this case, we just test and get DW_AT_bit_size and it should work.
    >
    > But I think BTF does not need this (DW_ATE_unsigned_1) for now.
    > I checked dwarf dump and it is mostly used for some arith operation
    > encoded in dump (in this case, e.g., shift by 1 bit)
    >
    > 0x000015cf: DW_TAG_base_type
    > DW_AT_name ("DW_ATE_unsigned_1")
    > DW_AT_encoding (DW_ATE_unsigned)
    > DW_AT_byte_size (0x00)
    >
    > 0x00010ed9: DW_TAG_formal_parameter
    > DW_AT_location (DW_OP_lit0, DW_OP_not,
    > DW_OP_convert (0x000015cf) "DW_ATE_unsigned_1", DW_OP_convert
    > (0x000015d4) "DW_ATE_unsigned_8", DW_OP_stack_value)
    > DW_AT_abstract_origin (0x00013984 "branch")
    >
    > Look at clang frontend, only the following types are encoded with
    > unsigned dwarf type.
    >
    > case BuiltinType::UShort:
    > case BuiltinType::UInt:
    > case BuiltinType::UInt128:
    > case BuiltinType::ULong:
    > case BuiltinType::WChar_U:
    > case BuiltinType::ULongLong:
    > Encoding = llvm::dwarf::DW_ATE_unsigned;
    > break;
    >
    >
    > > not, can we try to come up with some extension that doesn't require
    > > consumers to match magic names?
    > >

    You want me to upload mlx5_core.ko?

    When looking with llvm-dwarf for DW_ATE_unsigned_160:

    0x00d65616: DW_TAG_base_type
    DW_AT_name ("DW_ATE_unsigned_160")
    DW_AT_encoding (DW_ATE_unsigned)
    DW_AT_byte_size (0x14)

    If you need further information, please let me know.

    Thanks.

    - Sedat -

    \
     
     \ /
      Last update: 2021-02-06 19:12    [W:3.738 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site