From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) by sourceware.org (Postfix) with ESMTPS id 0B2E63855002 for ; Tue, 22 Jun 2021 20:53:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B2E63855002 Received: by mail-vk1-xa2f.google.com with SMTP id k16so39076vke.10 for ; Tue, 22 Jun 2021 13:53:09 -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=acPxz87MQ80/TxHzTK0iVbnQIKEiR0OI45fA1iZX/1I=; b=JAHOj629VSW2Jy8/L3wlqHL9cHdp6FPdVbnADNnTasEwkLttD6vaiYGHu8gokRWdAl EXITF0rgR8lNG3ZvHa0MEvterf6wdHNIYl0LIP3jhhtwRhB9Ar1hYaaoxzAQ0QKmqhEn 8eIRUDdjyrch+0KLG+CA7loJi/Xpmv+P2ipbTqTHKT6MDiw1xvdH0N/Lqkvj3olV0kAA Qhv01MOTXhBdS/ZeMEVnzdOhXtPRrhYHMiN3RsOHgwVXic5OdFrKtSIA5b3BtU/WjP10 d/icdjdi7c55Xk/PgVbNb6ycn/VZTbloOCMMbKoVqvxTrCLWs9JlYhZgZu2uKoS6UJ+b yEBg== X-Gm-Message-State: AOAM532fLcOCltENnn3O4Feo5pP+crrmvaC+UbCTL1VSZEmCwpMKPuKW VSkZQyyvual+gHmQNbCItwW+mkRDZidrRxp5fPI= X-Google-Smtp-Source: ABdhPJx79AAPEjCYqG1GO2Eo7fhs3Mb6Ahm7dKax5G4I+ypwP47vUJV/74vDk68cjkUSAllOyWyu0VVuvZqZt8WRcNQ= X-Received: by 2002:a1f:2fc4:: with SMTP id v187mr21414886vkv.4.1624395188680; Tue, 22 Jun 2021 13:53:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Blaikie Date: Tue, 22 Jun 2021 13:52:57 -0700 Message-ID: Subject: Re: [DWARF5] Is debug_line.dwo parsing and handling correct in GDB To: "Tomar, Sourabh Singh" Cc: "gdb@sourceware.org" , "paul.robinson@sony.com" , "Achra, Nitika" , "George, Jini Susan" , "Sharma, Alok Kumar" , "Kumar N, Bhuvanendra" , "E, Nagajyothi" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 20:53:11 -0000 On Thu, Jun 17, 2021 at 12:57 AM Tomar, Sourabh Singh < SourabhSingh.Tomar@amd.com> wrote: > Hello Everyone, > > > > Recently while investigating > https://sourceware.org/bugzilla/show_bug.cgi?id=27966 I stumbled upon the > > `.debug_line.dwo (AKA Specialized line table)` parsing part of the GDB. > > Glancing over it, it seems like the parsing of the Specialized line > table(.debug_line.dwo) is limited by the presence of type units. > > However apart from type units there are other consumers of > `.debug_line.dwo` such as `.debug_macro.dwo` for more context on this > > front please refer to following DWARFIssue: > http://dwarfstd.org/ShowIssue.php?issue=200602.1 > > > > Coming back to present situation, the question I have is the > `.debug_line.dwo` section consumptions is Okay in GDB? If so, Can somebody > > provide a possible testing scenario. As of now trunk GCC((GCC) 12.0.0 > 20210514) does not produce type units. > For what it's worth: GCC does produce type units, at least so far as I know - but what you might be hitting is that in DWARFv5 type units are in the .debug_info[.dwo] section, not the .debug_types[.dwo] section - so the absence of .debug_types section doesn't mean that type units aren't being produced. (I don't have a tot gcc build - mine's a little older and doesn't have some of the recent DWARFv5 work, I guess) I can't speak for GDB's handling of .debug_line.dwo, though. > Compilation tried: > > $ tot-gcc -fdebug-types-section -g macro.c > > $ tot-gcc -fdebug-types-section -gstrict-dwarf macro.c > > > > If GDB consumption of `.debug_line.dwo` is Okay, then how is it managing > the primary line table `.debug_line`(containing the address to line > mapping) part ? > > Does it parses the primary line table in a subsequent pass ? or the > primary line table is parsed first then a second pass needed to accommodate > information > > available in Specialized line table ? > > > > Please note: CLANG emits Specialized line table iff macro + split mode are > enabled i.e > > ``` > > $ clang -gdwarf-5 -gsplit-dwarf -fdebug_macro macro.c > > $ llvm-readelf -S macro.dwo | egrep "debug" > > * [ 2] .debug_macro.dwo PROGBITS 0000000000000000 000040 0004f2 > 00 E 0 0 1* > > [ 3] .debug_str_offsets.dwo PROGBITS 0000000000000000 000532 000580 > 00 E 0 0 1 > > [ 4] .debug_str.dwo PROGBITS 0000000000000000 000ab2 002275 01 > MSE 0 0 1 > > [ 5] .debug_info.dwo PROGBITS 0000000000000000 002d27 00003e > 00 E 0 0 1 > > [ 6] .debug_abbrev.dwo PROGBITS 0000000000000000 002d65 00003f > 00 E 0 0 1 > > * [ 7] .debug_line.dwo PROGBITS 0000000000000000 002da4 000056 > 00 E 0 0 1* > > ``` > > > > Any pointer, much appreciated! > > > > Thanks, > > Sourabh. >