Re: [Dwarf-discuss] The new Version Scheme for V6.

On Fri, Mar 28, 2025 at 10:24:25AM -0700, Cary Coutant wrote: > > > > Yeah. Strings are more expensive than just numbers (which can be done > > through DW_FORM_implicit_const) and for strings you'd need some agreed way > > how to compare what is newer and what is older. > > strverscmp, rpmvercmp,

Re: [Dwarf-discuss] The new Version Scheme for V6.

On Fri, Mar 28, 2025 at 08:30:48AM -0700, David Blaikie via Dwarf-discuss wrote: > I believe the intent is that version numbers are able to be compared > numerically. > > In any case, they are numbers per https://dwarfstd.org/issues/210419.1.html > - "A DW_AT_language_version attribute may be spec

[Dwarf-discuss] Default Lower Bound for Ada{2005,2012}

Hi! Similarly to the Fortran cases, https://dwarfstd.org/languages.html DW_LANG_Ada83 0x0003 1 DW_LANG_Ada95 0x000d 1 DW_LANG_Ada2005 0x002e 0 DW_LANG_Ada2012 0x002f 0 I admit I know nothing about Ada (CCing Tom if he can clarify), but I'd find it unexpected if Ada 83/95 d

Re: [Dwarf-discuss] Default Lower Bound for Fortran18

On Thu, Nov 21, 2024 at 05:22:48PM +0100, Mark Wielaard via Dwarf-discuss wrote: > The Default Lower Bound for DW_LANG_Fortran18 on > https://dwarfstd.org/languages.html is listed as 0. > I cannot find a reference for Fortran 2018 changing the default lower > bound for arrays from 1 to 0. I am a Fo

Re: [Dwarf-discuss] defaulting to C23 in GCC

On Wed, Nov 20, 2024 at 03:09:02PM +0100, Alexandra Petlanova Hajkova via Dwarf-discuss wrote: > GCC15 (to be released in April/May2025) will default to C23 instead of the > C17. > There is a new way to describe the language standard version used proposed > for DWARF6 but there is nothing like th

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

On Fri, Sep 13, 2024 at 01:46:26PM -0500, Lorenzo Gomez wrote: > That makes sense. Interestingly enough when I run with clang > "clang -gdwarf-5 -fdebug-macro -g3 -c macro_test.c -o macro_test_clang.o" > and dwarfdump with "dwarfdump macro_test_clang.o > macro_test_clang_dwarf" > > yields all the

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

On Fri, Sep 13, 2024 at 10:51:33AM -0500, Lorenzo Gomez wrote: > Thanks again for all of the insight into all this. The reason we're looking > into this is because we develop a tool that extracts dwarf info from an elf > file called juicer , which dumps > it

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

On Thu, Sep 12, 2024 at 05:10:01PM -0500, Lorenzo Gomez wrote: > Thanks so much for the detailed explanation. So clearly all the macros are > there as we can see from readelf. I ran it myself and can see all the > macros as David pointed out. And just to make sure I understand, this is > what I too

Re: [Dwarf-discuss] Macros after "#include" does not show up DWARF

On Thu, Sep 12, 2024 at 10:52:33AM -0700, David Blaikie via Dwarf-discuss wrote: > Looks probably like a bug in GCC and best discussed in their forum? (clang > seems to produce the macro in the macinfo if you compile with > `-fdebug-macro` (& you have to put some emitted entity (like a function > d

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

On Wed, Apr 24, 2024 at 02:57:17PM -0700, Adrian Prantl wrote: > > > > On Apr 24, 2024, at 2:49 PM, Jakub Jelinek wrote: > > > > On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss > > wrote: > >> # C standard release dates for DW_AT_language_version, clarify semantics >

Re: [Dwarf-discuss] Proposal: C standard release dates for DW_AT_language_version, clarify semantics

On Wed, Apr 24, 2024 at 02:25:37PM -0700, Adrian Prantl via Dwarf-discuss wrote: > # C standard release dates for DW_AT_language_version, clarify semantics > > ## Background > > The list of languages at https://dwarfstd.org/languages-v6.html does not list > release dates for the ISO C standard.

Re: [Dwarf-discuss] gfortran / gcc on Mac puts control characters in N_SO STABS

On Fri, Mar 15, 2024 at 01:25:26PM -0400, John DelSignore wrote: > FWIW, when TotalView reads the DWARF, there are no control characters in the > strings. GCC uses DW_FORM_strp (with the exception of too short strings where DW_FORM_string is always beneficial) if it detects assembler which suppor

Re: [Dwarf-discuss] gfortran / gcc on Mac puts control characters in N_SO STABS

On Wed, Mar 13, 2024 at 07:54:03PM +, John DelSignore via Dwarf-discuss wrote: > Strictly speaking, this is not a DWARF question, but it relates to DWARF > because on the Mac the Mach-O NLIST/STAB symbol table is used as an index > into DWARF symbols table. It's kind-of like Split-DWARF, but

Re: [Dwarf-discuss] Proposal: Error: DW_OP_entry_value description and examples

On Tue, Aug 08, 2023 at 04:21:57PM +, Metzger, Markus T via Dwarf-discuss wrote: > >### Section 2.5.1.7 Special Operations, p.37 > > > >The first sentence of the description of DW_OP_entry_value reads: > > > >The DW_OP_entry_value operation pushes the value that the described > >locati

Re: [Dwarf-discuss] ISSUE: vector types. V2

On Wed, Apr 12, 2023 at 01:05:14PM +0100, Pedro Alves wrote: > > I thought Ben has posted the details. > > In memory they look the same as 0 based arrays, but they often have > > different calling conventions (argument passing, returning), they support > > various arithmetic operations on them, in

Re: [Dwarf-discuss] ISSUE: vector types. V2

On Thu, Apr 06, 2023 at 07:52:32AM -0400, Ron Brender wrote: > Various thoughts... > > > Not sure if supporting dimensions in the way which is done > > for arrays is needed (I believe vector types are always one-dimensional > > indexed from 0). > > "always"? There are many element by element oper

Re: [Dwarf-discuss] ISSUE: vector types. V2

On Thu, Apr 06, 2023 at 10:47:02AM +, Metzger, Markus T wrote: > >I don't think this is a good idea, we should go for > >DW_TAG_vector_type > >instead IMHO. DW_AT_GNU_vector used to be a good idea as an extension, > >as mentioned the (generic) vector types are in many ways similar to arrays, >

Re: [Dwarf-discuss] ISSUE: vector types. V2

On Wed, Apr 05, 2023 at 07:16:35PM -0700, Ben Woodard via Dwarf-discuss wrote: > To distinguish these vector types from regular C arrays, GCC's DWARF > describes a vector type as an array with the DW_AT_GNU_vector > attribute.  Clang also supports the GCC vector extensions, and > describes the vect

Re: [Dwarf-Discuss] What does an "" file name mean?

On Wed, Nov 09, 2022 at 08:54:00AM -0500, John DelSignore via Dwarf-Discuss wrote: > On Ubuntu 22.04, the Python 3.9 DWARF debug information has compilation units > that look like this: > > Compilation Unit @ offset 0x0: >Length:0x1a14a (32-bit) >Version: 5 >Unit Type

Re: [Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings

On Tue, Jan 25, 2022 at 01:55:40PM +, paul.robin...@sony.com wrote: > > If s_float and f_float or t_float and g_float coexist on the same platform > > in the same ABI, I'm afraid DW_AT_precision to distinguish between them, > > Did you mean, DW_AT_precision isn't enough to distinguish between

Re: [Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings

On Mon, Jan 24, 2022 at 09:43:07PM -0500, John Reagan wrote: > Yes, on OpenVMS we have 2 32-bit floats (VAX f_float, IEEE s_float), 3 > 64-bit floats (VAX d_float, VAX g_float, IEEE t_float), and 1 128-bit > float (IEEE x_float). We had a 2nd 128-bit float back on the VAX but we > don't support th

Re: [Dwarf-Discuss] Multiple floating point types with the same size but different encodings

On Mon, Jan 24, 2022 at 04:52:38PM -0500, Jason Merrill wrote: > DW_ATE seems natural, since that's how we express the encoding of a base > type. OTOH, using DW_AT_precision would parallel DW_AT_digit_count for > fixed-point encodings. My concern is that it would be possible to have > multiple al

Re: [Dwarf-Discuss] Multiple floating point types with the same size but different encodings

On Mon, Jan 24, 2022 at 01:34:01PM +0100, Jakub Jelinek via Dwarf-Discuss wrote: > Which brings another question, shouldn't we add > > DW_ATE_complex_int > > as a standard code? Actually, we need to differentiate DW_ATE_complex_signed_int and DW_ATE_complex_unsigne

[Dwarf-Discuss] Multiple floating point types with the same size but different encodings

Hi! On powerpc64le-linux, we are in the middle of changing ABI of long double from the IBM double double format https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic to IEEE 754 quad (aka binary128) https://en.wikipedia.org/wiki/Quadruple-precision_floati

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Thu, Mar 11, 2021 at 11:30:05AM -0800, David Blaikie wrote: > Thanks! - is this proposed as a DWARF extension? I thought I remembered it 170427.1 I think. Note, what is emitted is different from what is being proposed, the problem with DW_LLE_* and DW_RLE_* is that they aren't easily extensibl

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Thu, Mar 11, 2021 at 01:05:06AM -0800, David Blaikie wrote: > What's your take on: > > 1) Fixing GDB to handle GCC's current output. I don't know what GDB will do, it is up to the GDB people. > 2) Fixing GCC to produce something maybe more standards conforming (to my > mind, ideally: ranges o

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 10:07:27PM -0800, David Blaikie wrote: > On Wed, Mar 10, 2021 at 9:38 PM Jakub Jelinek wrote: > > > On Wed, Mar 10, 2021 at 04:12:57PM -0800, David Blaikie via Dwarf-Discuss > > wrote: > > > On Wed, Mar 10, 2021 at 4:02 PM Cary Coutant wrote: > > > > > > > > > So in the e

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 04:12:57PM -0800, David Blaikie via Dwarf-Discuss wrote: > On Wed, Mar 10, 2021 at 4:02 PM Cary Coutant wrote: > > > > > So in the end the logical thing to do when encountering a > > > > DW_FORM_rnglistx in a split-unit, in order to support everybody, is > > > > probably t

Re: [Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

On Wed, Mar 10, 2021 at 01:16:24PM -0800, Cary Coutant wrote: > > But what about the DW_AT_ranges on the skeleton CU when using split DWARF? > > > > Are you suggesting that both LLVM and GCC's emission is incorrect - and > > that it's not possible to use rnglistx in the skeleton CU (instead you mu

[Dwarf-Discuss] Split Dwarf vs. CU DW_AT_ranges / DW_AT_low_pc placement

Hi! We got a report today that GCC even for -gdwarf-5 -gsplit-dwarf uses .debug_rnglists section + DW_AT_ranges + DW_AT_low_pc + DW_AT_rnglists_base attributes in the DW_TAG_skeleton_unit (and then some DW_AT_ranges in .debug_info.dwo that use DW_FORM_rnglistx, but no .debug_rnglists.dwo section).

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 09, 2021 at 04:32:35PM -0800, David Blaikie wrote: > Ah, OK. Hmm - do you have different call_site_parameters for registers > versus parameters? Or I guess a call_site_parameter without a > DW_AT_location and only a DW_AT_call_value? Yes, those DW_TAG_call_site_parameter DIEs have DW_A

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 09, 2021 at 03:22:35PM -0800, David Blaikie wrote: > So, when the consumer evaluates DW_OP_GNU_parameter_ref, it handles it > > similarly to DW_OP_entry_value, unwinds to caller if it can identify it, > > and just looks up if some value is specified for it in that particular > > caller.

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 09, 2021 at 11:43:54AM -0800, David Blaikie wrote: > Thanks for the details! So in this case GCC changes the ABI of foo(int x, > int y) to be equivalent to foo(int y) and the parameter description of 'y' No, it is actually equivalent to foo(void) but DW_TAG_call_site_parameter in those

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 09, 2021 at 11:16:01AM -0800, David Blaikie via Dwarf-Discuss wrote: > void f1(int i) { } > > to include a DW_AT_location with fbreg, nothing about how the ABI > represents 'i' - so that would be an ABI gap. > > In the cases where the compiler does modify any ABI-relevant properties,

Re: [Dwarf-Discuss] compilers generating ABI non-compliant function calls?

On Tue, Mar 09, 2021 at 10:05:04AM -0500, Andrew Cagney via Dwarf-Discuss wrote: > Is anyone aware of a compiler doing this (I figure with LTO there's a > strong incentive)? And if so, how is this described to the debugger. > The ABI / calling-convention is no longer on hand for filling in the > b

Re: [Dwarf-Discuss] dwarf stack operator for byte swap.

On Fri, Nov 08, 2019 at 06:51:52AM +, Chirag Patel via Dwarf-Discuss wrote: > Proposed changes to DWARF > --- > > 2.5.1.7 Special Operation > > Addition > > DW_OP_byte_swap > >The DW_OP_byte_swap operation pops the top stack entry, byte > swaps the

Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call

On Fri, Dec 07, 2018 at 08:58:42AM -0800, Cary Coutant via Dwarf-Discuss wrote: > And that's another reason why on PA-RISC and Itanium we have the rule > that the unwind info for the PC of the instruction following the call > must be accurate. With that rule, we do not have to anticipate or > compe

Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call

On Fri, Dec 07, 2018 at 08:28:06AM -0800, Michael Eager wrote: > > and in .debug_loc etc., I can provide say one location description for the > > range .L0 to .L1 (i.e. for instructions before the call > > instruction, another one e.g. for .L1 to .L2-1, valid on the call > > instruction, but not in

Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call

On Fri, Dec 07, 2018 at 07:57:23AM -0800, Michael Eager wrote: > On 12/07/2018 04:54 AM, Jakub Jelinek wrote: > > On Fri, Dec 07, 2018 at 12:36:39PM +, David Stenberg via Dwarf-Discuss > > wrote: > > > > For calls, we need to distinguish the locations that are valid in the caller > > on the c

Re: [Dwarf-Discuss] Location list entries for caller-saved registers at time of call

On Fri, Dec 07, 2018 at 12:36:39PM +, David Stenberg via Dwarf-Discuss wrote: For calls, we need to distinguish the locations that are valid in the caller on the call instruction before the call instruction has been executed, then locations that are valid while inside of the call and finally

Re: [Dwarf-Discuss] Alternate entry points

On Wed, Oct 24, 2018 at 01:00:26AM -0400, Rafik Zurob via Dwarf-Discuss wrote: > > I dug up gfortran 5.4, which does not emit DW_TAG_entry_point with my > > simple example program. Does anybody actually use it? > > IBM XL Fortran generates it. > > $ cat entry.f > subroutine foo(a) > integer a