lkml.org 
[lkml]   [2021]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
From
Date


On 2/6/21 11:28 AM, Sedat Dilek wrote:
> On Sat, Feb 6, 2021 at 8:22 PM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>
>> On Sat, Feb 6, 2021 at 8:17 PM Yonghong Song <yhs@fb.com> wrote:
>>>
>>>
>>>
>>> On 2/6/21 10:10 AM, Sedat Dilek wrote:
>>>> 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?
>>>
>>> I just sent out a patch. You are cc'ed. I also attached in this email.
>>> Yes, it would be great if you can upload mlx5_core.ko so I can
>>> double check with this DW_ATE_unsigned_160 which is really usual.
>>>
>>
>> Yupp, just built a new pahole :-).
>> Re-building linux-kernel...
>>
>> Will upload mlx5_core.ko - need zstd-ed it before.
>>
>
> Hmm, I guess you want a mlx5_core.ko with your patch applied-to-pahole-1.20 :-)?

this should work too. I want to check dwarf data. My patch won't impact
dwarf generation.

>
>> - Sedat -
>>
>>>>
>>>> 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 20:35    [W:0.104 / U:1.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site