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:44 AM, Sedat Dilek wrote:
> On Sat, Feb 6, 2021 at 8:33 PM Yonghong Song <yhs@fb.com> wrote:
>>
>>
>>
>> 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.
>>
>
> Usual Dropbox-Link:
>
> https://www.dropbox.com/sh/kvyh8ps7na0r1h5/AABfyNfDZ2bESse_bo4h05fFa?dl=0
>
> See "for-yhs" directory:
>
> 1. mlx5-module_yhs-v1 ("[PATCH dwarves] btf_encoder: sanitize
> non-regular int base type")
> 2. mlx5-module_yhs-dileks-v4 (with the last diff-v4 I tried successfully)

Thanks, with llvm-dwarfdump, I can see

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

0x00d88e81: DW_TAG_variable
DW_AT_location (indexed (0xad) loclist =
0x0005df42:
[0x0000000000088c8e, 0x0000000000088c97):
DW_OP_breg9 R9+0, DW_OP_convert (0x00d65616) "DW_ATE_unsigned_160",
DW_OP_convert (0x00d65607) "DW_ATE_unsigned_32", DW_OP_stack_value,
DW_OP_piece 0x4)
DW_AT_abstract_origin (0x00d88d37 "_v")


0x00d88d37: DW_TAG_variable
DW_AT_name ("_v")
DW_AT_decl_file
("/home/dileks/src/linux-kernel/git/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_ste.c")
DW_AT_decl_line (1198)
DW_AT_type (0x00d68835 "u32")

The source code at line 1198.
1198 DR_STE_SET_MASK_V(eth_l3_ipv4_5_tuple, bit_mask,
1199 source_port, mask, udp_sport);

This is for struct mlx5dr_match_spec.

struct mlx5dr_match_spec {
u32 smac_47_16; /* Source MAC address of incoming packet */
/* Incoming packet Ethertype - this is the Ethertype
* following the last VLAN tag of the packet
*/
u32 ethertype:16;
u32 smac_15_0:16;
...
u32 tcp_dport:16;
/* TCP source port.;tcp and udp sport/dport are mutually
exclusive */
u32 tcp_sport:16;
u32 ttl_hoplimit:8;
u32 reserved:24;
/* UDP destination port.;tcp and udp sport/dport are mutually
exclusive */
u32 udp_dport:16;
/* UDP source port.;tcp and udp sport/dport are mutually
exclusive */
u32 udp_sport:16;
/* IPv6 source address of incoming packets
* For IPv4 address use bits 31:0 (rest of the bits are reserved)
* This field should be qualified by an appropriate ethertype
*/
u32 src_ip_127_96;
...
}

which includes a bunch of bit fields and non-bit fields.

I have no idea why clang will generate
DW_OP_convert (0x00d65616) "DW_ATE_unsigned_160"
and possibly try to capture more semantic information?
But BTF should be able to safely ignore this as described
in my patch.

Thanks.

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