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
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 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
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,
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
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
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
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
;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
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
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
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
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
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 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
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
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
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
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 (
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
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
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!
Hi David,
There's no standard ABI document (that I could find). You might want to look in
the GDB sources on the off chance that it supported at some point.
Ultimately, the thing that matters is how the compilers you are using numbers
the registers. There is a decent description of the micropro
Inline...
On 5/5/25 18:31, David Broman wrote:
Thanks for the information.
There are unofficial patches to both gcc and gdb to support 6809. Neither of
them support DWARF.
As you said, MAME could in theory just come up with a register mapping, and
compiler writers (e.g., CMOC for 6809) would
25 matches
Mail list logo
