From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id A5F183858D1E for ; Wed, 1 Nov 2023 17:30:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A5F183858D1E 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 A5F183858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::436 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698859832; cv=none; b=bR8VO6izEhr5SGSpIaqSsM0kYTwbS18Cny290Qfok4pPljEyWwLvEtPqGWMFARplyWhfviLu7J+eTO5rCOclvy+YyptZtDhemLrCgwK/UiSmx425t5uiHHlnNakPRtdYT6m3wGq43PbGHSnLYGpTQUD9R7slhQRNKhZ6pYBj6J0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698859832; c=relaxed/simple; bh=k6o6X/zx3xAhsbwTcAt39fiNJGO9Sk4C+OpyvrxV/KA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=BPsrijbBZZ0AZyB0PiUwdveBlOBhcd6XWH0Z6aBdowsmb3RuhdYT4kO4C+jAxzFL4PU3R2J1aSTqU081JqmLzLNzBOwfVWrn3fPlcz2adGot3McMrUGowyp/crzOY6iRur8WsnvVwVYzVjqqS/7RJw7UJO+8RG8Zos9uMw+SiHA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6b201a93c9cso95697b3a.0 for ; Wed, 01 Nov 2023 10:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20230601.gappssmtp.com; s=20230601; t=1698859821; x=1699464621; 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=PcYC6HIfTKADMwOXQMQTIHst6mXCcuTI9IbYsaXBugo=; b=xm7BuMSOg7XduFXWDQ4qp8VxrrMK0fZOTc0Hfd5c1OhAizZR4gYin6liSk144JIczz 6qGvAdTCvvAJnXuXI1J+rIPIXYSHU9GRNRfkD2AkxKreha2XYQtax1j3DWF4MX12+hxo e1GiMwnLhSpGFoWKdMcJI44cJUjauTbyXlfYBrb/51GAnt09UA5eC5Qn2FGMMuXKTSoq uKxpaBfaiU/lsBw34KJucfb7VTXvLkY3xXXg+2KDaf+NQAXlBlpXAxaHmnhDoasb6iRv QJJvziK37pN0rrOJg4nHt6M+NZa0VsD0XGNvXet7HIXpJOD7A+Ty35dDmEmO7lp4c7gM iJfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698859821; x=1699464621; 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=PcYC6HIfTKADMwOXQMQTIHst6mXCcuTI9IbYsaXBugo=; b=Jo7pTrqL3ZFlH51hksxaDp47h6Z2/SLkvFHL5hq50Gkb+VBo5CioTuL9wILCQKM7hP kejR2YnAQpwqSprUrsXhkmEoXVYJja4vtYQUFNAi+3q+DgRiL0bqsDfreYdIe0ChvYDn ATeA1YaGGRenzzVGShEnftBN/OHH+2wYkXiXB8isKAaEkudt8F82zcbykp4kDxCcTw2J kaoB0lTgJAkXJCSktqqcXRDkL9psEtArquAuUVgJRigX4a7QADZyDKHKBXbyNn57/Foc /k/ueb47IZqGTgPusU/I6iLTGU29weuNy7o8tY6eT0smjNx7Y2YivEHT8of24k1bOpyg nDPQ== X-Gm-Message-State: AOJu0Yxw5Cnydxe+Mwju3ZO5BSqGGUfWHWV0sBhLOyR0SJy7Q/2nZDr9 Zsr2jbBiWekKimgYgBb9Wl9N6g4QdROV+RsEZUo3dQ== X-Google-Smtp-Source: AGHT+IEdPpUVe/F7tGA6XY1foV1v/Qm3gLqNrT5v49016Qaz4az8HML1Be+M5i7VHcnGV6cTtn6x5g== X-Received: by 2002:aa7:8881:0:b0:691:2d4:23b2 with SMTP id z1-20020aa78881000000b0069102d423b2mr15236797pfe.15.1698859820623; Wed, 01 Nov 2023 10:30:20 -0700 (PDT) Received: from telecaster ([2601:602:a300:3bc0::7aaf]) by smtp.gmail.com with ESMTPSA id c18-20020aa79532000000b006b2e07a6235sm1497318pfp.136.2023.11.01.10.30.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Nov 2023 10:30:20 -0700 (PDT) Date: Wed, 1 Nov 2023 10:30:19 -0700 From: Omar Sandoval To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH 07/14] libdw: Recognize .debug_[ct]u_index sections in dwarf_elf_begin Message-ID: References: <5837a252931d4a85079d29d08f8b6890ae070700.1695837512.git.osandov@fb.com> <051e05da49fc84a0100f1865f0fca1d501cbeb49.camel@klomp.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <051e05da49fc84a0100f1865f0fca1d501cbeb49.camel@klomp.org> X-Spam-Status: No, score=-5.5 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 Wed, Nov 01, 2023 at 03:03:57PM +0100, Mark Wielaard wrote: > Hi Omar, > > On Wed, 2023-09-27 at 11:20 -0700, Omar Sandoval wrote: > > From: Omar Sandoval > > > > DWARF package (.dwp) files have a .debug_cu_index section and, > > optionally, a .debug_tu_index section. Add them to the list of DWARF > > sections. > > > > Unfortunately, it's not that simple: the other debug sections in a dwp > > file have names ending with .dwo, which confuses the checks introduced > > by commit 5b21e70216b8 ("libdw: dwarf_elf_begin should use either plain, > > dwo or lto DWARF sections."). So, we also have to special case > > .debug_cu_index and .debug_tu_index in scn_dwarf_type and check_section > > to treat them as TYPE_DWO sections. > > This seems to work, but I wonder if we should have a specific TYPE_DWP? I tried this, and it made check_section even more confusing (because then we need a more complicated check than result->type == section type). I came to the same conclusion that since this is internal for now, it didn't really matter. Although maybe the name TYPE_SPLIT would make more sense now rather than overloading TYPE_DWO. When this becomes public, separate TYPE_DWO and TYPE_DWP types might be nicer so that a hypothetical dwarf_get_type function could tell you whether you got a dwo file or a dwp file. > It doesn't really matter now, because the enum dwarf_type is only used > internally. But I was hoping to extend the dwarf_begin interface with a > flag so that you can open a DWARF as a specific type. For example there > are single file split DWARF files. Which contain both "plain" and > ".dwo" sections. Currently you can only open them as "plain", but there > are actually two "views" of such files. > > https://sourceware.org/bugzilla/show_bug.cgi?id=28573 > > Do you think there are reasons to open a file as either TYPE_DWO or > TYPE_DWP? Or doesn't that not make sense? If we were to treat a dwp file as a dwo file, I guess we'd have to pretend it only contained one unit and ignore the rest, which I don't think makes much sense. So even if we had separate types for them, I don't know if we should allow that.