From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 188C83858424 for ; Fri, 23 Feb 2024 00:53:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 188C83858424 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=osandov.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=osandov.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 188C83858424 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708649604; cv=none; b=EGLgTL/WMBR8mecOmCQYEO8yLkrvDRe1npzqEnuhZtlfI4xyhF0nUfl84DHe1xK6rdPmeymKUKbluu9fycyovsWWnLH8q9hEQWxFwLW2plE8yLZmZfgGzexq5vqUGnTsYAXF0i1wQdO7b2a6DnB7pQbJdPhkuwFoJ1/NfS9OmNg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708649604; c=relaxed/simple; bh=JlgEsB5jeM7MdH4eg69+KnLkKzoyyms8RTMMLyP3PgM=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=fpikNrzYXZCRbeFNFTqs0Bbl8EGYwjtjSk5dVl5t+BEJUrxYrHqsQOUj1739R0rL4c6LGs+cqI67eGx/Nbb2lGNcGeoj1R/SFcuPnNlmTdWxn1curBv/8tYZQFNx1B31UsWU7CwuOipz50+xtU9DVO9aUlE/HJDhHvbplOOgRjs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-6da9c834646so215457b3a.3 for ; Thu, 22 Feb 2024 16:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20230601.gappssmtp.com; s=20230601; t=1708649602; x=1709254402; darn=sourceware.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=C5Nw3NG0eOVAf+P62VU+yIIAlUyR8HRwUwb7Ecygt68=; b=aT9CWDM6j9lpwb6OzTIbgn4nmoBkSrcwdGxJaWmT6hB8mOYvEW+aH3wLOxMGDsE6me zU7Fc67mlnwjG3t09Ne+PRQ5cMWGVjxCkHq9Nf7gZzxmn0tGMe+V6tvridV5womc9UIU we9bvZUwwcR82cJs+3Welj57g/VS7p+JocvFup4McxbB8SzNavm59G2FwGoUA8BuZaXO bwb9wAYa1JJOWvXPSKUbJrp+c/NgS8ljjU52QfnLLQMwRS568qDbZf3efAreCN9DtvvQ tH2NZsEaxcHwB2Scde2XXB1yUhaRDp9cW5EqDgzv2N7U+yO9ladVR2FrHFRgEzq819W4 bWVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708649602; x=1709254402; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=C5Nw3NG0eOVAf+P62VU+yIIAlUyR8HRwUwb7Ecygt68=; b=hhbEBCbSA5hz7Ed4chAtPI9z2vSFHB8igBERlY7KRmWwsTXaW1IYf+G5Pf/Vdd4K16 9w8NZegZonuHDDDRhwpG2bweyr7YS7rhHCK7zleiCN79SSNsuLG7nfAX4NltiBVymLtm kGMoh6Zp3YwAqy0BEC7PjFEJNxderkRrv4PzAGexAmgmLRk3Z754+VLvtmPTbc/i6KVk SL1+wZ2AmU2E8t6gKCDTifuMTKmnTonOLfVBJlaeWodZNId+6J0ZzPFCaDeffAmQxaC2 fDQISe2um4PZHZCDkZTjozYNcRwlbcLz2IoXxtkpkOkJW+tAxiRgrNYVkix6Au3yaumd 5yvQ== X-Gm-Message-State: AOJu0Yyr0TCsp9c8UnKk6NP7p6io1fFl5QEZmwRnsmv9DDLXa1jk1Fjf NRSzkh2sTl3nmci2LoQ1jDAly+peIgCRqNuH0M+SNUp3NGfSOx6gihgqf0x4SYECQqsuDVbdINt K X-Google-Smtp-Source: AGHT+IGRgx2XE3DjB5kseq8TUjvkehv76ms3yUBWngkLuHtcKYscRbB/51FoUHk0mtkDU3N6mAVubA== X-Received: by 2002:a05:6a21:1485:b0:1a0:9ab5:1e83 with SMTP id od5-20020a056a21148500b001a09ab51e83mr546260pzb.24.1708649601651; Thu, 22 Feb 2024 16:53:21 -0800 (PST) Received: from telecaster ([2620:10d:c090:400::4:ca24]) by smtp.gmail.com with ESMTPSA id sw14-20020a17090b2c8e00b00296d9c4d5f0sm117911pjb.10.2024.02.22.16.53.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Feb 2024 16:53:21 -0800 (PST) Date: Thu, 22 Feb 2024 16:53:19 -0800 From: Omar Sandoval To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH v2 3/4] libdw: Apply DWARF package file section offsets where appropriate Message-ID: References: <824d09edb009fd7cf3befcd871742f8089793c5e.1701854319.git.osandov@fb.com> <2f2aedc63120761bd82663442cef6a5330c80cd6.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2f2aedc63120761bd82663442cef6a5330c80cd6.camel@klomp.org> X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Feb 16, 2024 at 04:00:47PM +0100, Mark Wielaard wrote: > Hi Omar, > > On Wed, 2023-12-06 at 01:22 -0800, Omar Sandoval wrote: > > The final piece of DWARF package file support is that offsets have to be > > interpreted relative to the section offset from the package index. > > .debug_abbrev.dwo is already covered, so sprinkle around calls to > > dwarf_cu_dwp_section_info for the remaining sections: .debug_line.dwo, > > .debug_loclists.dwo/.debug_loc.dwo, .debug_str_offsets.dwo, > > .debug_macro.dwo/.debug_macinfo.dwo, and .debug_rnglists.dwo. With all > > of that in place, we can finally test various libdw functions on dwp > > files. > > So the offsets for DW_SECT_INFO, DW_SECT_TYPES and DW_SECT_ABBREV were > already taken into account when setting up a cu from a dwp. > > With this patch __libdw_cu_str_off_base/str_offsets_base_off handles > DW_SECT_STR_OFFSETS which is used in dwarf_formstring and > dwarf_getmacros. > > __libdw_cu_ranges_base handles DW_SECT_RNGLISTS, which is used by > dwarf_ranges. And __libdw_formptr has a special case for > DW_FORM_sec_offset for IDX_debug_ranges && version < 5 && unit_type == > DW_UT_split_compile to also uses __libdw_cu_ranges_base. > > __libdw_cu_locs_base handles DW_SECT_LOCLISTS which is used in > dwarf_getlocation through initial_offset. I do wonder why the special > case in __libdw_formptr isn't needed here too. > > dwarf_getmacros handles DW_SECT_MACRO through get_offset_from. And when > the macros need to refer to the line table, it also handles > DW_SECT_LINE. > > Don't we also need to handle DW_SECT_LINE in dwarf_getsrclines and > dwarf_next_lines when looking for DW_AT_stmt_list? .debug_line is the odd one out in split DWARF: the skeleton file contains the full .debug_line, and the DWO or DWP files have a skeleton .debug_line.dwo that only contains the directory and file name tables (for DW_AT_file and macro info to reference). dwarf_getsrclines and co. read from the skeleton file, not the DWP file, meaning they shouldn't use DW_SECT_LINE. > > * libdw/dwarf_getmacros.c (get_macinfo_table): Call > > dwarf_cu_dwp_section_info and add offset to line_offset. > > (get_offset_from): Call dwarf_cu_dwp_section_info and add offset > > to *retp. > > * libdw/libdwP.h (str_offsets_base_off): Call > > dwarf_cu_dwp_section_info and add offset. > > (__libdw_cu_ranges_base): Ditto. > > (__libdw_cu_locs_base): Ditto. > > * libdw/dwarf_getlocation.c (initial_offset): Call > > dwarf_cu_dwp_section_info and add offset to start_offset. > > * tests/run-varlocs.sh: Check testfile-dwp-5 and testfile-dwp-4. > > * tests/run-all-dwarf-ranges.sh: Check testfile-dwp-5 and > > testfile-dwp-4. > > * tests/run-dwarf-getmacros.sh: Check testfile-dwp-5 and > > testfile-dwp-4-strict. > > * tests/run-get-units-split.sh: Check testfile-dwp-5, > > testfile-dwp-4, and testfile-dwp-4-strict. > > The code and tests look good. run-varlocs.sh seems good, which seems to > confirm DW_SECT_LOCLISTS is handled correctly (but why doesn't it need > a hack similar to ranges in __libdw_formptr?). I think it's because ranges have the uniquely weird behavior in DWARF 4 GNU Debug Fission that DW_AT_GNU_ranges_base is in the skeleton file but used to interpret the split file. This was cleaned up for DWARF 5 (as I documented in commit c9c9ffae725009b192b40e2d89035f353ae7055f), and there was no base attribute for location lists in DWARF 4, so it's not applicable. > We might want to add a test for run-next-lines.sh and run-next- > files.sh? Good idea, I'll send an updated version with those tests. Thanks! Omar