Messages in this thread |  | | Subject | Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type | From | Yonghong Song <> | Date | Sat, 6 Feb 2021 12:12:55 -0800 |
| |
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 - >>>>>>
|  |