On 4/23/25 22:46, Cary Coutant via Dwarf-discuss wrote:
Looking at the DWARF generated by GCC (and I'm guessing LLVM does the same), I
see vtable_elem_location attributes that look like this:
<1b8> DW_AT_vtable_elem_location: 2 byte block: 10 0 (DW_OP_constu: 0)
This is not correct DWARF!
Is the discriminant value always a constant? Perhaps DWARF should say, "The
value of this attribute is of class constant." Table 2.3 defines attribute
class constant as, "One, two, four, eight or sixteen bytes of uninterpreted
data, or data encoded in the variable length format known as LEB128 (
In-line below...
On 1/13/25 20:10, David Anderson via Dwarf-discuss wrote:
On 1/13/25 11:35, David Blaikie via Dwarf-discuss wrote:
I guess Jon is referring to the 16th field in the header, "directories
(sequence of directory names)" which uses the same encoding system (but
a separate format fiel
Hi,
Section 6.2 (Line Number Information) of the DWARF 5 spec does not seem to
constrain which DW_LNCT content types are valid for directory entries, or at
least I couldn't find where it does.
Are DW_LNCT_directory_index, DW_LNCT_timestamp, DW_LNCT_size, and/or
DW_LNCT_MD5 content types valid
Hi,
I think the best way to encode the information depends on details of the
processor architecture. The IA-64 (Intel Itanium architecture) had a VLIW
instruction encoding with a 128-bit instruction bundle consisting of three
41-bit instruction slots per bundle plus a 5-bit template indicating
FWIW, when TotalView reads the DWARF, there are no control characters in the
strings.
Cheers, John D.
On 3/15/24 13:12, Adrian Prantl wrote:
On Mar 15, 2024, at 9:22 AM, John DelSignore via Dwarf-discuss
<mailto:dwarf-discuss@lists.dwarfstd.org>
wrote:
Thanks for looking at this. I
? I'm curious now.
-- adrian
On Mar 15, 2024, at 7:41 AM, John DelSignore
<mailto:jdelsign...@perforce.com> wrote:
Hi Adrian,
Thanks for the reply. As far as I can tell, neither gcc nor gfortran produce
N_SO stabs when -gdwarf-4 is used. It is the Apple ld-classic linker that is
generating
Hi Adrian,
Thanks for the reply. As far as I can tell, neither gcc nor gfortran produce
N_SO stabs when -gdwarf-4 is used. It is the Apple ld-classic linker that is
generating the N_SO stabs and inserting them into the Mach-O nlist symbol
table. I believe that the linker is reading the DWARF in
Hi Jakub,
Thanks for the reply. My answer inline below...
On 3/13/24 16:29, Jakub Jelinek wrote:
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
Hi,
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 was invented long
before Split-DWARF was added to DWARF 5.
On a Mac OS 14 Sonoma M
Hi,
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 was invented long
before Split-DWARF was added to DWARF 5.
On a Mac OS 14 Sonoma M
If you can’t find it in an ABI document… You might want to look at the GDB
sources, which usually contains the code to handle various targets, probably in
a file named “gdb/mips*tdep.h”.
Cheers, John D.
From: Dwarf-discuss
On Behalf
Of Seva Alekseyev via Dwarf-discuss
Sent: Wednesday, August
On 4/21/23 16:36, David Blaikie wrote:
On Fri, Apr 21, 2023 at 12:44 PM John DelSignore
mailto:jdelsign...@perforce.com>> wrote:
Well, it took a long time to compile 5 CUs that contained your test code, and
things were looking promising, but the link failed:
rocm2 42 04/21 15:14
get rid of .debug_aranges. :-)
Cheers, John D.
On 4/21/23 13:28, John DelSignore wrote:
Thanks David, this is useful. I'll see what I can cobble together.
Cheers, John D.
On 4/20/23 21:58, David Blaikie wrote:
Oh, and I guess you could always make something even more artificial by hand -
if you comp
;s about half
the size of the .debug_info in this program.
On Thu, Apr 20, 2023 at 7:08 AM John DelSignore via Dwarf-discuss
mailto:dwarf-discuss@lists.dwarfstd.org>>
wrote:
Is anyone aware of an open-source program or test program that when compiled
and built on Linux x86_64, results
Is anyone aware of an open-source program or test program that when compiled
and built on Linux x86_64, results in a .debug_info section that is greater
than 4GB? I'm looking for a test program (realistic or not) that contains
32-bit DWARF CUs in a .debug_info section that is about 5GB long, or
I agree that the web page you reference should be updated (or perhaps deleted),
but you can find an up to date table in Appendix G of the DWARF 5 spec.
Cheers, John D.
On 3/21/23 19:03, Ben Woodard via Dwarf-discuss wrote:
> It looks like
> https://nam12.safelinks.protection.outlook.com/?url=ht
Hi Martin,
AMD faced the same problem you are describing when generating DWARF for optimized code running on AMD GPUs. After considering several alternatives, they came up with a solution that is described in complete detail here:
https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebug
Hi,
I'm hoping someone from Intel sees this message and can definitively answer the
following question: Do any of the Intel compilers still generate
DW_OP_INTEL_bit_piece=0xe8? If not, do you know the last version of the
compiler that did?
Back in 2007, I added support for the Intel Bi-Endian
You probably already know this, but I'm pretty sure that "GHS" is Green Hills
Software: https://www.ghs.com/products/compiler.html
TotalView supported their compiler on the BBN Butterfly in the early '90s, but
that predated DWARF support. Maybe someone at Green Hills can tell you what
they mean
Hi John,
The OpenMP Tools Workgroup has been discussing a very similar issue for OpenMP threads and TARGET regions (e.g.,regions offloaded to GPUs). Tony Tye at AMD (who is also a DWARF committee member) proposed a model where the compiler can generate DWARF that
would tell a consumer (most lik
FYI, Tony Tye and his team at AMD created a DWARF Proposal for heterogeneous
debugging, which is generally useful but required to debug optimized code for
GPUs. It directly addresses the issue of how to model different address spaces
and makes location descriptions first-class objects that can b
Hi Paul,
TotalView recently got snagged on this with a GNU DebugFission style
Split-DWARF .dwo file. A customer had things set up such that -gz=zlib was the
default for their compiler, and it was producing compressed debug sections in
the .dwo file, where the only hint that the section was comp
Hi Scott,
Question: What does the DW_TAG_compile_unit look like for an embedded source
file? For example, what does the DW_AT_name and DW_AT_comp_dir look like?
Cheers, John D.
On 01/31/18 17:05, sc...@scottlinder.com wrote:
> Hello all,
>
> I am a compiler engineer at AMD, working on tools fo
On 02/03/17 17:35, Jakub Jelinek wrote:
> On Fri, Feb 03, 2017 at 02:29:49PM -0800, David Anderson wrote:
>> On 02/03/2017 12:21 PM, John DelSignore wrote:
>>> Hi,
>>>
>>> I've been poking around looking for Split DWARF producers. As far as I
>>
On 02/03/17 17:29, David Anderson wrote:
> On 02/03/2017 12:21 PM, John DelSignore wrote:
>> Hi,
>>
>> I've been poking around looking for Split DWARF producers. As far as I
>> can tell, no compiler or tool chain currently implements Split DWARF as
>> describe
Hi,
I've been poking around looking for Split DWARF producers. As far
as I can tell, no compiler or tool chain currently implements
Split DWARF as described in the current DWARF5 draft standard. Is
that correct?
The GNU, Intel, and LLVM compilers implement the G
Jakub Jelinek wrote:
On Wed, Mar 09, 2016 at 01:24:37PM -0500, John DelSignore wrote:
I agree completely with Jakub. Defining multiple "float" types that
have varying byte-sizes, bit-sizes, and bit-offsets seems like a big
mistake to me.
The debugger has to kn
Jakub Jelinek wrote:
On Wed, Mar 09, 2016 at 08:36:44AM -0800, Michael Eager wrote:
How is the "float" type described?
A value which is contained in a register larger than the size of
the value should be described by a DW_TAG_base_type. (DWARF 4,
Sect. 5.1, bottom of page 75).
F
Hi Mark,
IMHO, the compiler should be picking a canonical order for the
qualifiers in the DWARF, just like it does for name mangling:
% cat xxx.cxx
void fpcvi(const volatile int*){}
void fpvci(volatile const int*){}
% g++ -g -c xxx.cxx
% nm -C xxx.o
T fpcvi(int const volatile*)
0
cessarily "std" related.
The real expert, of course, should be our very own John
Bishop...
Yes, I was hoping he would be able to explain what's going on.
Cheers, John D.
My 2 cents...
Ron
On Mon, Sep 15, 2014 at 1:32 PM, John
DelSignore <j
Hi Michael,
Thanks for the reply. In-line below...
Michael Eager wrote:
> On 09/15/14 10:32, John DelSignore wrote:
>> Hi,
>>
>> TotalView has a customer that has C++ code that produces the
>> following DWARF with the Intel 12.1
>> compiler:
>
> ICC ge
Hi,
TotalView has a customer that has C++ code that produces the following
DWARF with the Intel 12.1 compiler:
<0><1192a2>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_comp_dir : ...SNIPPED...
DW_AT_language : 4 (C++)
DW_AT_name : ...SNIPPED...
DW_AT_prod
Hi Mark,
I looked at TotalView's DWARF reader, and omitting DW_AT_byte_size from
DW_TAG_enumeration_type would require code changes. TotalView treats enums as
self-contained types with a discrete byte length; in other words, enum types
are not based on some other kind of type like "int" types.
Hi Cary,
In a previous message, you asked:
> Isn't DW_FORM_block* the form you're looking for?
And in the message below, you identified that the standard already allows the
block forms for constants, and the values are represented in "target
architecture" format. So yes, this is exactly what I
In Fortran if you declare a variable as a "parameter", the compiler creates a
named constant. The language allows named constants of any intrinsic type, that
is, a numeric (integer, real, or complex) value, a character value (including
strings), or a logical value. Given that strings are allowed
36 matches
Mail list logo
