From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B25F9385E442; Fri, 24 Jun 2022 21:31:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B25F9385E442 From: "wcohen at redhat dot com" To: systemtap@sourceware.org Subject: [Bug translator/29037] Systemtap unable to find struct bitfield members for gcc11 compiled code Date: Fri, 24 Jun 2022 21:31:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: translator X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: wcohen at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2022 21:31:09 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29037 William Cohen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #4 from William Cohen --- Thinking through plan for DW_AT_data_bit_offset handling One of the restrictions is that dwarf_getlocation_addr expects a DW_AT_data_member_location doesn't understand DW_AT_data_bit_offset attribute. The dwarf_getlocation_addr returns a DWARF_E_NO_LOC_VALUE if there is no DW_AT_data_member_location. Maybe synthesize a DW_AT_data_member_location from DW_AT_data_bit_offset and the data type size in dwflpp.cxx dwflpp::find_struct_member. It is a bit more complicated than DW_AT_data_bit_offset/8 as that might not be start of the data type holding the bit field. There are a number of places where DW_AT_bit_offset is checked in dwflpp.cxx. Those places will need to be expanded to handle DW_AT_data_bit_offset. Need to handle the differences between DW_AT_data_bit_offset and DW_AT_bit_offset: -DW_AT_data_bit_offset little-endian, but DW_AT_bit_offset is big-endian -DW_AT_data_bit_offset is from start of struct, DW_AT_bit_offset is from start of DW_AT_data_member_location Places where DW_AT_bit_offset used in dwflpp.cxx functions: get_bitfield and dwflpp::translate_final_fetch_or_store. Also have DW_AT_bit_offset in tapsets.cxx dwarf_pretty_print::recurse_struct_members. Generating an equivalent to DW_AT_data_member_location: member_location =3D (data_bit_offset / byte_size) * byte_size; Generating bit offset from DW_AT_data_member_location bit_offset =3D data_bit_offset - member_location; At this point have a partial patch on wcohen/pr29037 to address pr29037 on https://sourceware.org/git/?p=3Dsystemtap.git;a=3Dshortlog;h=3Drefs/heads/w= cohen/pr29037 . One sticking point point is creating a new DW_AT_data_member_location attribute. Copying the DW_AT_data_bit_offset attribute and overwriting the DW_AT_data_bit_offset with DW_AT_data_member_location is easy. However, modifying the valp field with the correct value for formudata() to read is not so obvious. Another issue that looks like that is going to come up is PR28334 if the structure is small enough to be passed in a registers. Systemtap doesn't handle extracting a item from a register unless it is in the lsb bits of the register. --=20 You are receiving this mail because: You are the assignee for the bug.=