On Sat, Feb 6, 2021 at 9:13 PM Yonghong Song <yhs@xxxxxx> wrote:
>
>
>
> On 2/6/21 11:44 AM, Sedat Dilek wrote:
> > On Sat, Feb 6, 2021 at 8:33 PM Yonghong Song <yhs@xxxxxx> wrote:
> >>
> >>
> >>
> >> On 2/6/21 11:28 AM, Sedat Dilek wrote:
> >>> On Sat, Feb 6, 2021 at 8:22 PM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
> >>>>
> >>>> On Sat, Feb 6, 2021 at 8:17 PM Yonghong Song <yhs@xxxxxx> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2/6/21 10:10 AM, Sedat Dilek wrote:
> >>>>>> On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song <yhs@xxxxxx> 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.
>
[ CC Fangrui - the only guy I know who might comment on this ]
Fangrui, feel free to comment?
Get the patch "[PATCH dwarves] btf_encoder: sanitize non-regular int
base type" from Yonghong Son:
link="https://lore.kernel.org/r/20210206191350.830616-1-yhs@xxxxxx";
b4 -d am $link
I commented the success in the other thread.
Sorry for cross-posting.
Big Thank-You Yonghong!
- Sedat -
- Sedat -
> >
> > - 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 -
> >>>>>>
