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
Thanks for looking at this. I sent a separate email with the object file
attached directly to you.
FWIW, using od -c to dump the string table, you can see that ^L (form feed),
which is the character that ends up in the first N_SO string, immediately
precedes the directory path:
00032202
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
to
compile with clang) - 5 of these (could stamp them out by including this file
into a few other source files & just changing the `main` function to some other
name in each)
This specifically doesn't push the .debug_str section as hard - it's about half
the size of the .debug_info i
s specifically doesn't push the .debug_str section as hard - it'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 pro
;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
23 matches
Mail list logo
