From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by sourceware.org (Postfix) with ESMTPS id 387203857C64 for ; Sat, 29 Aug 2020 15:44:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 387203857C64 Received: by mail-io1-xd42.google.com with SMTP id m23so2020014iol.8 for ; Sat, 29 Aug 2020 08:44:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IktkN6xV5y+gDJ1g6vhPsIsJekQN0tmnuKiSohByYHw=; b=N0ff917l6esQuaNSF93E/Kk3+HOYw+YVpjW0AO2N8By6RpUiWtvf1Mc1q1EE0mN7vl w7LFO16rTpvWGbcIZYUB1hdIjXjy7M/fKZY0TD46xifHOWTWdjWNNgtBo1tt1QLDbPGz LjJB8tkBwvoSCMQGTXXNaf+scGHxlDvHrjeqF7pUa0jHrI/spby1YQGfNAuOSM6JKR4u RpKyV8VMmoHNfKBEK5ZMRZUj+ImL9xhZNm3TAYGMr6lCK77pBM0C1shriryd2i4QabyH isbakdkPWFMrGYYBmPttlEM8gELBXLITLLtCisI67Udu+S5sDZYg03Q83iAajsgY6HKB hi/g== X-Gm-Message-State: AOAM531HxTEDONQn129/ni92QDNpSfi4M6OKSCJpwBQ/QwRrJ5ASnRlP YNu+CDAdfpWX1Oub2eiTYKgblj4/MGbvwb/38u4= X-Google-Smtp-Source: ABdhPJy+Urj1oqCtwaiKJl+9QAE28lI61RtmUza6wL/zh2BblxVOrB05tvloGw1OGo+z22eWkLLkoz+Ro+iMA5f5sis= X-Received: by 2002:a05:6602:15d3:: with SMTP id f19mr2876860iow.91.1598715846077; Sat, 29 Aug 2020 08:44:06 -0700 (PDT) MIME-Version: 1.0 References: <20200824125658.22526-1-mark@klomp.org> <20200824125658.22526-6-mark@klomp.org> <20200826213729.GG3062@wildebeest.org> <20200829122337.GA3051@wildebeest.org> <20200829152312.GB3051@wildebeest.org> In-Reply-To: <20200829152312.GB3051@wildebeest.org> From: "H.J. Lu" Date: Sat, 29 Aug 2020 08:43:30 -0700 Message-ID: Subject: Re: Duplicate .debug_lines (Was: [PATCH 5/5] Add --gdwarf-5 to ASM_SPEC) To: Mark Wielaard Cc: GCC Patches , Jakub Jelinek , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2020 15:44:09 -0000 On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard wrote: > > Hi, > > On Sat, Aug 29, 2020 at 07:34:35AM -0700, H.J. Lu wrote: > > On Sat, Aug 29, 2020 at 5:24 AM Mark Wielaard wrote: > > > On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote: > > > > On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard wrote: > > > > > Would it be possible to have something like the following in gas, so > > > > > that it doesn't try generating a .debug_line section if there already > > > > > is one, even when -gdwarf-N is given (unless the assembly also > > > > > contains .loc directives because that shows the user is really > > > > > confused)? > > > > > > > > > > diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c > > > > > index e4ba56d82ba..c0c09f4e9d0 100644 > > > > > --- a/gas/dwarf2dbg.c > > > > > +++ b/gas/dwarf2dbg.c > > > > > @@ -2626,7 +2626,7 @@ dwarf2_init (void) > > > > > > > > > > > > > > > /* Finish the dwarf2 debug sections. We emit .debug.line if there > > > > > - were any .file/.loc directives, or --gdwarf2 was given, or if the > > > > > + were any .file/.loc directives, or --gdwarf2 was given, and if the > > > > > file has a non-empty .debug_info section and an empty .debug_line > > > > > section. If we emit .debug_line, and the .debug_info section is > > > > > empty, we also emit .debug_info, .debug_aranges and .debug_abbrev. > > > > > @@ -2650,9 +2650,16 @@ dwarf2_finish (void) > > > > > empty_debug_line = line_seg == NULL || !seg_not_empty_p (line_seg); > > > > > > > > > > /* We can't construct a new debug_line section if we already have one. > > > > > - Give an error. */ > > > > > + Give an error if we have seen any .loc, otherwise trust the user > > > > > + knows what they are doing and want to generate the .debug_line > > > > > + (and all other debug sections) themselves. */ > > > > > if (all_segs && !empty_debug_line) > > > > > - as_fatal ("duplicate .debug_line sections"); > > > > > + { > > > > > + if (dwarf2_loc_directive_seen) > > > > > + as_fatal ("duplicate .debug_line sections"); > > > > > + else > > > > > + return; > > > > > + } > > > > > > > > > > if ((!all_segs && emit_other_sections) > > > > > || (!emit_other_sections && !empty_debug_line)) > > > > > > > > I have run into this issue before. "as -g" shouldn't silently > > > > generate incorrect debug info when input assembly codes already > > > > contain debug directives. AS should either issue an error or > > > > ignore -g. > > > > > > Right, that is what this patch does for .debug_line. gas already > > > doesn't generate .debug_info, .debug_aranges and .debug_abbrev if > > > .debug_info is non-empty, even if -g is given. > > > > > > > In either case, we need a testcase to verify it. > > > > > > Right, and the documentation needs to be update. But first we have to > > > know whether the gas maintainers think this is the right approach. > > > > -g should be ignored in this case. > > I am not sure what you mean by "in this case", or what precisely it > means to "ignore -g". > > My proposal, and what my strawman patch implements, is that gas will > generate a .debug_line section when -g is given and the debug types is > DWARF (just as it does now). Unless there is a non-empty .debug_line > section already created by the input assembly and the input assembly > does not contain any .loc directive then gas will not try to generate > a .debug_line section itself but leaves the non-empty .debug_line as > is (currently gas will generate an error in this case). But if the > input assembly does contain both .loc directives and creates a > non-empty .debug line section gas will still generate an error (as it > does now, whether or not the input assembly contains any .loc > directives). > > Does this sound sane? What if there is a .file directive, but without .loc directive, like $ gcc -c x.c -Wa,-g -- H.J.