From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by sourceware.org (Postfix) with ESMTPS id A2B493858D34 for ; Sun, 14 Apr 2024 07:15:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A2B493858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=obs.cr Authentication-Results: sourceware.org; spf=none smtp.mailfrom=obs.cr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A2B493858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c2e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713078960; cv=none; b=DeNdUiHSinRZ0K+bFz2wxHGpQ4Q5NfBL4K7kKg1y+B8OoOZ6LRn/LHdM+dCUUdI57DRv6u76Yqeyst5L+sFP2jiVCtJLqBW5ziObUd/cH3mSaI9BSYuTAS8/BzOuuPlNYEbiqMLbQ0KUBcqMcbvrwIAQiTKzcZS7zuxEpNqY+YY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713078960; c=relaxed/simple; bh=cyH+nuJgvVpQ3N/IXXDBcrF1DznOG9Wm30h/w1WBsjM=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=FnpjNEiccKKSceHKjiTX0VA4zo2wS2KgYN0tgt1tGyvha78Ql6X9915y0DvDFQIlHQ8Nu0qm/9Ow5XBR7lTZ2qZf2LFuU0uwoBdQsv89RVM68EKggDqXoCbpXxtaCs1E/V3ReYYU+DkNrXASbVTp1xF0Y4frU9+TnqCPk08mIoE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-5aa17c29ba0so1365448eaf.3 for ; Sun, 14 Apr 2024 00:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=obs-cr.20230601.gappssmtp.com; s=20230601; t=1713078958; x=1713683758; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BCjL4ZqKNqvmOKDu4HvvHBSCgoVPYEFZOrEbOhkpk00=; b=mhZbc/FVeHZo6qVBymsrCWQ6Q27RayVo8gLNRwTfVlft+B14jCug/JbFjdjgpT9ogP 6r4SUTKqOh0B7nsMf95LmIpIXhLtvQY3iq0RulIeHtrQaRjWxbwAjF4Ctuw/9KAVRrFR z5nWh96FdKwdBAXsX7a+1CWkuCua7wxVE6sVgD1ToZK0VS8yCYEBSuwPtkSY1atZzz03 3CIg8+2TjfN/xXe1cR1sE46eU5/RM/x8p5z0FU+07XOsyvxbdQkS+7RXLvw1iCmoMayD apV5GqCLpF/KwPyoQIRM6+NbOIwIyfxg52uSXWpnZFi2G4mpTlwMVHEui8UhqlhcufuB 8wFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713078958; x=1713683758; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BCjL4ZqKNqvmOKDu4HvvHBSCgoVPYEFZOrEbOhkpk00=; b=rqZAJAc+UHAe1upLTg9XBXK2GmC8nzM1Z70x/qVuBqcg8QlQbzCuQuhMhtCUXl+Vfj cHM7oS+OAHyv1coIo+lS0dbwEtLCvdlAwfA9CttWHH7ycvWhucXKy5CIh5LpQCxtMMKm nYqG9O3+lDHFkYcTIX7WPZB/8wV7YLTe8ILNXffqVyDt4VTNnVqGo5FaMWvburhIEkQ0 +yuRYIDSQUUnf05iGxHQ9HZUNpHqWAM+CAKL5S6+opInbbY5Om67A9GBITv6ZuaKUoDH sjhH+9VDf8GDyMKC/5lMxH3SzyA154ENLFlBHaPf/kJx5/w2MiK8hvGLW0xlUcKqQjM2 wosg== X-Gm-Message-State: AOJu0YyQsUBkzqDQGi4ckgOA9RqkzylFL18F7a5fQOH8NWQbWu6m1YOY Lss6WkGMsbiyeOderKQ8DQT2lrZIMhNb5lyqV7ahyUrU07aWojobcDJiI3+o2Hhx697KM/9hbLT xQhqGaZOyFnmZieq3s5WFanZb55w+SCrZfBOiog== X-Google-Smtp-Source: AGHT+IEfA5PhvQY2ZVPuW7RLIj9Ce58Ji2B1b0C1Ir8AnBPMHBdF15GUH+h0qS6ksB8VBc/YqQl7H+cCTtr3RZo+B0o= X-Received: by 2002:a05:6359:5144:b0:186:27f9:d71a with SMTP id oc4-20020a056359514400b0018627f9d71amr9133313rwb.12.1713078957833; Sun, 14 Apr 2024 00:15:57 -0700 (PDT) MIME-Version: 1.0 References: <20240412185525.171292-1-hawkinsw@obs.cr> In-Reply-To: From: Will Hawkins Date: Sun, 14 Apr 2024 03:15:46 -0400 Message-ID: Subject: Re: [PATCH v5] gdb: Support embedded source in DWARF To: Tom de Vries Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP 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 Sun, Apr 14, 2024 at 3:01=E2=80=AFAM Tom de Vries wro= te: > > On 4/14/24 04:50, Will Hawkins wrote: > > On Fri, Apr 12, 2024 at 4:12=E2=80=AFPM Tom de Vries = wrote: > >> > >> On 4/12/24 20:55, Will Hawkins wrote: > >>> + DW_LNE_set_address main_end > >>> + line [gdb_get_line_number "main end"] > >>> + DW_LNS_copy > >>> + > >>> + DW_LNE_end_sequence > >>> + } > >> I've just submitted a patch series designed to catch this ( > >> https://sourceware.org/pipermail/gdb-patches/2024-April/207922.html ). > >> > >> The copy produces a line table entry with empty address range (because > >> the end_sequence is at the same address),. > >> > >> This is probably not what you intended. > > > > What I get for doing copy/paste! A v6 is on its way! Thank you for the > > eagle eyes! > > > > It's just that I spent some time fixing all test-cases with this > problem, so I happened to spot it. Anyway, thanks for following up. > > > On a semi-related note, it appears that "many" of the dwarf2 tests do > > not properly specify > > > > add_dummy_cus 0 > > > > in their invocation of Dwarf::assemble resulting in two CUs being > > generated in the .S file. This does not appear to cause problems for > > the tests, but if you run the generated binaries through a "dwarf > > validator", e.g., llvm-dwarfdump, they will report errors. I have > > requested an account on the gdb bugzilla to report a bug and will file > > a related patch as a fix, if that is okay with you? > > The dummy cu's are there by default, intentionally, as explained here ( > https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dcommit;h=3D5ef670d81= fd222ae5edfa1428ad48710f5e10d35 > ). In brief, it tries to make sure that when writing a dwarf assembly > test-case on one platform it will work on another. > > If this causes problems with llvm-dwarfdump, we can look into fixing > that. So, yes, please file a PR. > > But I'd look into a way of fixing this that doesn't require > "add_dummy_cus 0". Interesting. So, as I understand it, forcing CUs for the file being compiled (hello.c in the example you cited) to be somewhere other than the beginning of the .debug_info sections allowed you to catch additional bugs. In order to draw out similar bugs on platforms where the "main" CU goes first by default, you added the dummy CU feature. Am I understanding that correctly? If so, that's really neat. I will file a bug and then work on PR that makes the dummy cu feature "compatible" with llvm-dwarfdump. It could obviously also be an issue with the llvm-dwarfdump tool, too. I have contributed to LLDB, too, and would be more than happy to work with them if the problems is really in their tool. Thank you for the follow up! Will > > Thanks, > - Tom >