Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type

[Yonghong Song]

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.

> > - 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 -