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

2024-03-15 Thread John DelSignore via Dwarf-discuss 
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 sent a separate email with the object file 
attached directly to you.

>From my quick investigation the problem seems to be that gfortran uses a 
>DW_FORM_string for the compile unit's name (rather than a DW_FORM_strp)


  DW_AT_name [DW_FORM_string]   ("/nfs/homes/jdelsign/hello.c")

and ld might have an off-by-one error when decoding the FORM (that part is 
speculation on my end based on that dwarfdump can decode the string fine, but 
it could also be a bug in gfortran and dwarfdump skips the control character 
when printing).

-- adrian



CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

2024-03-15 Thread John DelSignore via Dwarf-discuss 
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   -   g   d   w   a   r   f   -   4  \0  \f   /   n   f
0003240s   /   h   o   m   e   s   /   j   d   e   l   s   i   g   n
0003260/   h   e   l   l   o   .   c  \0   /   t   m   p  \0  \0  \0

Seems like an off-by-one error in the linker, and gcc / gfortran just happens 
to tickle it.

Cheers, John D.

On 3/15/24 11:58, Adrian Prantl wrote:

You don't often get email from apra...@apple.com. 
Learn why this is important

Could you send me an example .o file that reproduces the issue? I'm curious now.

-- adrian

On Mar 15, 2024, at 7:41 AM, John DelSignore 
 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 the N_SO stabs and inserting them into the Mach-O nlist symbol 
table. I believe that the linker is reading the DWARF information out of the 
object file and using the compilation unit DIE to determine the string values 
for the N_SO stabs.

In the newest set of Apple ld sources I could find, I can see that the 
following function in OutputFile.cpp generates N_SO and N_OSO stabs:

  void OutputFile::synthesizeDebugNotes(ld::Internal& state)

and seems to be using the DWARF information.

My guess is that there is something about the way gcc and gfortran generate the 
compilation unit DIE that causes the linker to generate:

N_SO 

N_SO 

For example:

dc3-mac-tvt4 39 03/15 10:38 /tmp % gcc-mp-13 -gdwarf-4 ~/hello.c -c
dc3-mac-tvt4 40 03/15 10:38 /tmp % gcc-mp-13 hello.o -o hello
dc3-mac-tvt4 41 03/15 10:39 /tmp % nm -ap hello | cat -v | grep -F ' SO '
 - 01 SO
 - 00 SO /tmp/^L/nfs/homes/jdelsign/
 - 00 SO hello.c
 - 01 SO
 - 00 SO 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc13/gcc13/work/build/x86_64-apple-darwin23/libgcc/^A/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc13/gcc13/work/gcc-13.2.0/libgcc/
 - 00 SO emutls.c
 - 01 SO
dc3-mac-tvt4 42 03/15 10:39 /tmp %

Notice that the control characters in two "first" SO stabs.

Do you agree this is a linker bug?

Thanks, John D.

On 3/14/24 14:34, Adrian Prantl wrote:

The N_OSO stabs entries are indeed added by the linker 
(https://wiki.dwarfstd.org/Apple's_%22Lazy%22_DWARF_Scheme.md).
Having done a quick scan through the linker sources I was not able to pinpoint 
the place where this path concatenation is happening.

> FWIW, I have not seen a similar problem with Apple's "cc", which is clang 
> compiler. It does not generate the working directory in the N_SO stabs:

Assuming that that is indeed the root cause, it might be best to modify 
gfortran to no longer emit N_SO stabs entries in the object file.

Adrian




CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.




CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

2024-03-15 Thread John DelSignore via Dwarf-discuss 
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 information out of the 
object file and using the compilation unit DIE to determine the string values 
for the N_SO stabs.

In the newest set of Apple ld sources I could find, I can see that the 
following function in OutputFile.cpp generates N_SO and N_OSO stabs:

  void OutputFile::synthesizeDebugNotes(ld::Internal& state)

and seems to be using the DWARF information.

My guess is that there is something about the way gcc and gfortran generate the 
compilation unit DIE that causes the linker to generate:

N_SO 

N_SO 

For example:

dc3-mac-tvt4 39 03/15 10:38 /tmp % gcc-mp-13 -gdwarf-4 ~/hello.c -c
dc3-mac-tvt4 40 03/15 10:38 /tmp % gcc-mp-13 hello.o -o hello
dc3-mac-tvt4 41 03/15 10:39 /tmp % nm -ap hello | cat -v | grep -F ' SO '
 - 01 SO
 - 00 SO /tmp/^L/nfs/homes/jdelsign/
 - 00 SO hello.c
 - 01 SO
 - 00 SO 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc13/gcc13/work/build/x86_64-apple-darwin23/libgcc/^A/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc13/gcc13/work/gcc-13.2.0/libgcc/
 - 00 SO emutls.c
 - 01 SO
dc3-mac-tvt4 42 03/15 10:39 /tmp %

Notice that the control characters in two "first" SO stabs.

Do you agree this is a linker bug?

Thanks, John D.

On 3/14/24 14:34, Adrian Prantl wrote:

The N_OSO stabs entries are indeed added by the linker 
(https://wiki.dwarfstd.org/Apple's_%22Lazy%22_DWARF_Scheme.md).
Having done a quick scan through the linker sources I was not able to pinpoint 
the place where this path concatenation is happening.

> FWIW, I have not seen a similar problem with Apple's "cc", which is clang 
> compiler. It does not generate the working directory in the N_SO stabs:

Assuming that that is indeed the root cause, it might be best to modify 
gfortran to no longer emit N_SO stabs entries in the object file.

Adrian




CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

2024-03-13 Thread John DelSignore via Dwarf-discuss 
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/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.


Are you sure it is gfortran and not some other program that introduces this?

I think it's likely that it is not the gfortran / gcc compiler, and it is 
something that happens during linking. The object file contains no STABS at 
all, and the DWARF produced by the compiler (with -gdwarf-4) looks good.

Do you see it in gfortran-mp-13 -gdwarf-4 -S output?

No, the assembler looks OK:

dc3-mac-tvt4 224 03/13 17:37 ~ % grep jdelsign hello.s
.file 1 "/nfs/homes/jdelsign/hello.c"
.ascii "/nfs/homes/jdelsign/hello.c\0"
.ascii "/nfs/homes/jdelsign\0"
dc3-mac-tvt4 225 03/13 17:37 ~ %

Or in the object file with -c?  Then it could be introduced by the
assembler.

Not the object file either, AFAICT. As I said, the object file contains no 
STABS at all:

dc3-mac-tvt4 225 03/13 17:37 ~ % gcc-mp-13 -gdwarf-4 -c ~/hello.c
dc3-mac-tvt4 226 03/13 17:40 ~ % nm -ap hello.o
00a0 s lC0
00cb s lC1
0150 s EH_frame1
00e0 D ___emutls_v.ticker
 T _main
 U ___emutls_get_address
 U ___stdoutp
 U _fflush
 U _printf
 U _putchar
dc3-mac-tvt4 227 03/13 17:40 ~ %

Or it could be introduced by the linker or by other tools (dsymutil?).

I think it's probably the linker, or whatever tool builds the Mach-O STABS 
index:

dc3-mac-tvt4 231 03/13 18:04 ~ % gcc-mp-13 -o hello hello.o
dc3-mac-tvt4 232 03/13 18:04 ~ % nm -ap hello | grep SO | cat -v | grep jdelsign
 - 00 SO /nfs/homes/jdelsign/^L/nfs/homes/jdelsign/
65f21d4e - 03 0001   OSO /System/Volumes/Data/nfs/homes/jdelsign/hello.o
dc3-mac-tvt4 233 03/13 18:04 ~ %

Notice the ^L in the N_SO, which is the first time I saw a control character 
higher than ^D.

If I add -v to the link command, here's what it prints:

dc3-mac-tvt4 233 03/13 18:04 ~ % gcc-mp-13 -o hello hello.o -v
Using built-in specs.
COLLECT_GCC=gcc-mp-13
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin23/13.2.0/lto-wrapper
Target: x86_64-apple-darwin23
Configured with: 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc13/gcc13/work/gcc-13.2.0/configure
 --prefix=/opt/local --build=x86_64-apple-darwin23 
--enable-languages=c,c++,objc,obj-c++,lto,fortran,jit 
--libdir=/opt/local/lib/gcc13 --includedir=/opt/local/include/gcc13 
--infodir=/opt/local/share/info --mandir=/opt/local/share/man 
--datarootdir=/opt/local/share/gcc-13 --with-local-prefix=/opt/local 
--with-system-zlib --disable-nls --program-suffix=-mp-13 
--with-gxx-include-dir=/opt/local/include/gcc13/c++/ --with-gmp=/opt/local 
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local 
--with-zstd=/opt/local --enable-checking=release --disable-multilib 
--enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug 
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld-classic 
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket 
--enable-host-shared --with-darwin-extra-rpath=/opt/local/lib/libgcc 
--with-libiconv-prefix=/opt/local --disable-tls 
--with-gxx-libcxx-include-dir=/opt/local/libexec/gcc13/libc++/include/c++/v1 
--with-pkgversion='MacPorts gcc13 13.2.0_4+stdlib_flag' 
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (MacPorts gcc13 13.2.0_4+stdlib_flag)
COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin23/13.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin23/13.2.0/:/opt/local/libexec/gcc/x86_64-apple-darwin23/:/opt/local/lib/gcc13/gcc/x86_64-apple-darwin23/13.2.0/:/opt/local/lib/gcc13/gcc/x86_64-apple-darwin23/
LIBRARY_PATH=/opt/local/lib/gcc13/gcc/x86_64-apple-darwin23/13.2.0/:/opt/local/lib/gcc13/gcc/x86_64-apple-darwin23/13.2.0/../../../
COLLECT_GCC_OPTIONS='-o' 'hello' '-v' '-mmacosx-version-min=14.0.0' 
'-asm_macosx_version_min=14.0' '-nodefaultexport' '-mtune=core2' '-dumpdir' 
'hello.'
 /opt/local/libexec/gcc/x86_64-apple-darwin23/13.2.0/collect2 -syslibroot 
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/ -dynamic -arch x86_64 
-platform_version macos 14.0.0 0.0 -o hello 
-L/opt/local/lib/gcc13/gcc/x86_64-apple-darwin23/13.2.0 
-L/opt/local/lib/gcc13/gcc/x86_64-apple-darwin23/13.2.0/../../.. hello.o 
-lemutls_w -lgcc -lSystem -no_compact_unwin

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

2024-03-13 Thread John DelSignore via Dwarf-discuss 
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 M2 system, I'm seeing gfortran and gcc puts control 
characters in N_SO STABS:

dc3-mac-tvt3 36 02/16 9:20 ~ % gfortran-mp-13 -gdwarf-4 
~/src/totalview.develop/debugger/src/tests/src/tx_f90_1module.f90
dc3-mac-tvt3 37 02/16 9:20 ~ % nm -ap a.out | cat -v | grep SO | grep -F '^'
 - 00 SO 
/nfs/homes/jdelsign/^B/nfs/homes/jdelsign/src/totalview.develop/debugger/src/tests/src/
dc3-mac-tvt3 38 02/16 9:21 ~ %

dc3-mac-tvt3 43 02/16 9:41 ~ % g++-mp-13 -gdwarf-4 
~/src/totalview.develop/debugger/src/tests/src/tx_hello.cxx
dc3-mac-tvt3 44 02/16 9:41 ~ % nm -ap a.out | cat -v | grep SO | grep -F '^'
 - 00 SO 
/nfs/homes/jdelsign/^D/nfs/homes/jdelsign/src/totalview.develop/debugger/src/tests/src/
dc3-mac-tvt3 45 02/16 9:41 ~ %

Above, notice the ^B and ^D. I have also seen ^A used. Apparently, the control 
character separates the current working directory from the directory path of 
the file passed to the compiler.

Does anyone know if this is a "feature" or a "bug"? Is it document somewhere?

Here are all of the STABS for the above g++ compile:

 - 00 SO 
/nfs/homes/jdelsign/^D/nfs/homes/jdelsign/src/totalview.develop/debugger/src/tests/src/
 - 00 SO tx_hello.cxx
65cf7425 - 00 0001   OSO 
/var/folders/sm/hl1mjmg569g9yh_x_6fm889w0017hg/T//ccapF4uA.o
00013f3c - 01  BNSYM
00013f3c - 01    FUN _main
005c - 00    FUN
00013f3c - 01  ENSYM
 - 01 SO

And here is the matching DWARF CU:

0x000b: DW_TAG_compile_unit
  DW_AT_producer("GNU C++17 13.2.0 -fPIC 
-mmacosx-version-min=14.0.0 -mlittle-endian -mabi=lp64 -gdwarf-4")
  DW_AT_language(DW_LANG_C_plus_plus)
  DW_AT_name
("/nfs/homes/jdelsign/src/totalview.develop/debugger/src/tests/src/tx_hello.cxx")
  DW_AT_comp_dir("/nfs/homes/jdelsign")
  DW_AT_GNU_pubnames(true)
  DW_AT_low_pc  (0x00013f3c)
  DW_AT_high_pc (0x00013f98)
  DW_AT_stmt_list   (0x)

The first N_SO is supposed to be the directory and the second is the file name. 
Notice that the second N_SO has no directory path. Given that the second N_SO 
is just the base name, having the current working directory and the directory 
path of the file passed to the compiler is actually helpful, because it 
provides the same level of detail in the DWARF CU.

I was thinking that the debugger could look for a control character in the 
first N_SO string split the current working directory from the directory path, 
but if it's a bug in the compiler maybe that's not a good idea.

Thanks, John D.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

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

2024-02-16 Thread John DelSignore via Dwarf-discuss 
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 M2 system, I'm seeing gfortran and gcc puts control 
characters in N_SO STABS:

dc3-mac-tvt3 36 02/16 9:20 ~ % gfortran-mp-13 -gdwarf-4 
~/src/totalview.develop/debugger/src/tests/src/tx_f90_1module.f90
dc3-mac-tvt3 37 02/16 9:20 ~ % nm -ap a.out | cat -v | grep SO | grep -F '^'
 - 00 SO 
/nfs/homes/jdelsign/^B/nfs/homes/jdelsign/src/totalview.develop/debugger/src/tests/src/
dc3-mac-tvt3 38 02/16 9:21 ~ %

dc3-mac-tvt3 43 02/16 9:41 ~ % g++-mp-13 -gdwarf-4 
~/src/totalview.develop/debugger/src/tests/src/tx_hello.cxx
dc3-mac-tvt3 44 02/16 9:41 ~ % nm -ap a.out | cat -v | grep SO | grep -F '^'
 - 00 SO 
/nfs/homes/jdelsign/^D/nfs/homes/jdelsign/src/totalview.develop/debugger/src/tests/src/
dc3-mac-tvt3 45 02/16 9:41 ~ %

Above, notice the ^B and ^D. I have also seen ^A used. Apparently, the control 
character separates the current working directory from the directory path of 
the file passed to the compiler.

Does anyone know if this is a "feature" or a "bug"? Is it document somewhere?

Here are all of the STABS for the above g++ compile:

 - 00 SO 
/nfs/homes/jdelsign/^D/nfs/homes/jdelsign/src/totalview.develop/debugger/src/tests/src/
 - 00 SO tx_hello.cxx
65cf7425 - 00 0001   OSO 
/var/folders/sm/hl1mjmg569g9yh_x_6fm889w0017hg/T//ccapF4uA.o
00013f3c - 01  BNSYM
00013f3c - 01    FUN _main
005c - 00    FUN
00013f3c - 01  ENSYM
 - 01 SO

And here is the matching DWARF CU:

0x000b: DW_TAG_compile_unit
  DW_AT_producer("GNU C++17 13.2.0 -fPIC 
-mmacosx-version-min=14.0.0 -mlittle-endian -mabi=lp64 -gdwarf-4")
  DW_AT_language(DW_LANG_C_plus_plus)
  DW_AT_name
("/nfs/homes/jdelsign/src/totalview.develop/debugger/src/tests/src/tx_hello.cxx")
  DW_AT_comp_dir("/nfs/homes/jdelsign")
  DW_AT_GNU_pubnames(true)
  DW_AT_low_pc  (0x00013f3c)
  DW_AT_high_pc (0x00013f98)
  DW_AT_stmt_list   (0x)

The first N_SO is supposed to be the directory and the second is the file name. 
Notice that the second N_SO has no directory path. Given that the second N_SO 
is just the base name, having the current working directory and the directory 
path of the file passed to the compiler is actually helpful, because it 
provides the same level of detail in the DWARF CU.

I was thinking that the debugger could look for a control character in the 
first N_SO string split the current working directory from the directory path, 
but if it's a bug in the compiler maybe that's not a good idea.

Thanks, John D.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] DWARF register numbers on MIPS

2023-08-16 Thread John DelSignore via Dwarf-discuss 
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 16, 2023 11:23 AM
To: dwarf-discuss@lists.dwarfstd.org
Subject: [Dwarf-discuss] DWARF register numbers on MIPS


What is the canonical mapping between DWARF register numbers and MIPS32 CPU 
registers, please? The first 32 ones are the general purpose registers, but 
what about beyond that (e. g. lo/hi)?

A link to an authoritative document would be most welcome. DWARF proper doesn't 
document this kind of thing, it's usually a part of the ABI, but the ABI 
handbook doesn't seem to mention DWARF.

CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

2023-04-21 Thread John DelSignore via Dwarf-discuss 
pen source community.

Looks like clang dodged all of those problems somehow:

rocm2 60 04/21 16:58 /build/jdelsign/fatty % llvm-dwarfdump fatty | grep 
"Compile Unit"
0x: Compile Unit: length = 0x461a1e96, format = DWARF32, version = 
0x0005, unit_type = DW_UT_compile, abbr_offset = 0x, addr_size = 0x08 (next 
unit at 0x461a1e9a)
0x461a1e9a: Compile Unit: length = 0x461a1e99, format = DWARF32, version = 
0x0005, unit_type = DW_UT_compile, abbr_offset = 0x0148, addr_size = 0x08 (next 
unit at 0x8c343d37)
0x8c343d37: Compile Unit: length = 0x461a1e99, format = DWARF32, version = 
0x0005, unit_type = DW_UT_compile, abbr_offset = 0x0292, addr_size = 0x08 (next 
unit at 0xd24e5bd4)
0xd24e5bd4: Compile Unit: length = 0x461a1e99, format = DWARF32, version = 
0x0005, unit_type = DW_UT_compile, abbr_offset = 0x03dc, addr_size = 0x08 (next 
unit at 0x118687a71)
0x118687a71: Compile Unit: length = 0x461a1e99, format = DWARF32, version = 
0x0005, unit_type = DW_UT_compile, abbr_offset = 0x0526, addr_size = 0x08 (next 
unit at 0x15e82990e)
rocm2 61 04/21 17:13 /build/jdelsign/fatty %

This should give the debuggers something to chew on for a while.

Cheers, John D.


- Dave


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 compile some random code with -g to assembly, you could then just pad 
out a .debug_info contribution with lots of zeros (there are some assembly 
directives for that, I think, but don't know assembly that well off hand) - 
would make it arbitrarily large without the need to tax the compiler creating 
novel/real DWARF, etc.

On Thu, Apr 20, 2023 at 6:54 PM David Blaikie 
mailto:dblai...@gmail.com>> wrote:
I /believe/ that Chromium (maybe specifically on ARM? not sure) may have 
hit/had problems with the 4GB limit - probably trivially if you build with 
clang but pass `-fstandalone-debug` which disables many type 
reduction/deduplication strategies.

If you want something more standalone... this:


#define MEMBERS(BASE) \
  int BASE##0 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##1 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##2 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##3 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##4 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##5 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##6 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##7 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##8 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##9 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int);
template
struct t1 {
  MEMBERS(f0)
  MEMBERS(f1)
  MEMBERS(f2)
  MEMBERS(f3)
  MEMBERS(f4)
  MEMBERS(f5)
  MEMBERS(f6)
  MEMBERS(f7)
  MEMBERS(f8)
  MEMBERS(f9)
};
#define ITER(A, B)\
  template  \
  struct A { \
B v0;   \
B v1;   \
B v2;   \
B v3;   \
B v4;   \
B v5;   \
B v6;   \
B v7;   \
B v8;   \
B v9;   \
  };
ITER(t2, t1);
ITER(t3, t2);
ITER(t4, t3);
ITER(t5, t4);
ITER(t6, t5);
ITER(t7, t6);
ITER(top, t7);
int main() {
  t6<> v;
}

Doesn't quite hit 4GB, it's about 1.2GB in .debug_info (& takes 2.5 minutes 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 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 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 longer.

Thanks, John D.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

--
Dwarf-discuss mailing list
Dwa

Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

2023-04-21 Thread John DelSignore via Dwarf-discuss 
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 /build/jdelsign/fatty % make
g++ -g -c fatty4.cxx -o fatty4.o
g++ -g -c fatty5.cxx -o fatty5.o
g++ -g -o fatty fatty.o fatty2.o fatty3.o fatty4.o fatty5.o
fatty5.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32 against 
`.debug_info'
collect2: error: ld returned 1 exit status
make: *** [Makefile:5: fatty] Error 1
rocm2 43 04/21 15:39 /build/jdelsign/fatty %

I guess I'm now in favor of the proposal to 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 compile some random code with -g to assembly, you could then just pad 
out a .debug_info contribution with lots of zeros (there are some assembly 
directives for that, I think, but don't know assembly that well off hand) - 
would make it arbitrarily large without the need to tax the compiler creating 
novel/real DWARF, etc.

On Thu, Apr 20, 2023 at 6:54 PM David Blaikie 
mailto:dblai...@gmail.com>> wrote:
I /believe/ that Chromium (maybe specifically on ARM? not sure) may have 
hit/had problems with the 4GB limit - probably trivially if you build with 
clang but pass `-fstandalone-debug` which disables many type 
reduction/deduplication strategies.

If you want something more standalone... this:


#define MEMBERS(BASE) \
  int BASE##0 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##1 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##2 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##3 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##4 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##5 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##6 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##7 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##8 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##9 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int);
template
struct t1 {
  MEMBERS(f0)
  MEMBERS(f1)
  MEMBERS(f2)
  MEMBERS(f3)
  MEMBERS(f4)
  MEMBERS(f5)
  MEMBERS(f6)
  MEMBERS(f7)
  MEMBERS(f8)
  MEMBERS(f9)
};
#define ITER(A, B)\
  template  \
  struct A { \
B v0;   \
B v1;   \
B v2;   \
B v3;   \
B v4;   \
B v5;   \
B v6;   \
B v7;   \
B v8;   \
B v9;   \
  };
ITER(t2, t1);
ITER(t3, t2);
ITER(t4, t3);
ITER(t5, t4);
ITER(t6, t5);
ITER(t7, t6);
ITER(top, t7);
int main() {
  t6<> v;
}

Doesn't quite hit 4GB, it's about 1.2GB in .debug_info (& takes 2.5 minutes 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 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 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 longer.

Thanks, John D.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org<mailto:Dwarf-discuss@lists.dwarfstd.org>
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss<https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss>


CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailin

Re: [Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

2023-04-21 Thread John DelSignore via Dwarf-discuss 
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 compile some random code with -g to assembly, you could then just pad 
out a .debug_info contribution with lots of zeros (there are some assembly 
directives for that, I think, but don't know assembly that well off hand) - 
would make it arbitrarily large without the need to tax the compiler creating 
novel/real DWARF, etc.

On Thu, Apr 20, 2023 at 6:54 PM David Blaikie 
mailto:dblai...@gmail.com>> wrote:
I /believe/ that Chromium (maybe specifically on ARM? not sure) may have 
hit/had problems with the 4GB limit - probably trivially if you build with 
clang but pass `-fstandalone-debug` which disables many type 
reduction/deduplication strategies.

If you want something more standalone... this:


#define MEMBERS(BASE) \
  int BASE##0 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##1 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##2 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##3 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##4 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##5 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##6 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##7 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##8 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int); \
  int BASE##9 (int, int, int, int, int, int, int, int, int, int, int, int, int, 
int, int, int, int, int, int, int);
template
struct t1 {
  MEMBERS(f0)
  MEMBERS(f1)
  MEMBERS(f2)
  MEMBERS(f3)
  MEMBERS(f4)
  MEMBERS(f5)
  MEMBERS(f6)
  MEMBERS(f7)
  MEMBERS(f8)
  MEMBERS(f9)
};
#define ITER(A, B)\
  template  \
  struct A { \
B v0;   \
B v1;   \
B v2;   \
B v3;   \
B v4;   \
B v5;   \
B v6;   \
B v7;   \
B v8;   \
B v9;   \
  };
ITER(t2, t1);
ITER(t3, t2);
ITER(t4, t3);
ITER(t5, t4);
ITER(t6, t5);
ITER(t7, t6);
ITER(top, t7);
int main() {
  t6<> v;
}

Doesn't quite hit 4GB, it's about 1.2GB in .debug_info (& takes 2.5 minutes 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 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 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 longer.

Thanks, John D.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

--
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org<mailto:Dwarf-discuss@lists.dwarfstd.org>
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss<https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss>


CAUTION: This email originated from outside of the organization. Do not click 
on links or open attachments unless you recognize the sender and know the 
content is safe.


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

[Dwarf-discuss] Seeking a test program with a >4GB .debug_info section

2023-04-20 Thread John DelSignore via Dwarf-discuss 
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 longer.

Thanks, John D.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-discuss] ISSUE: update Dwarf_Version_Numbers.md for DWARF5

2023-03-22 Thread John DelSignore via Dwarf-discuss 
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=https%3A%2F%2Fwiki.dwarfstd.org%2FDwarf_Version_Numbers.md&data=05%7C01%7Cjdelsignore%40perforce.com%7C96ab83bfa7064925670d08db2a6079ff%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638150366099554716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X%2BCN4KtoCySJ2iTGmOZUZe%2B%2BFNRdiu1JO%2FNYVFyq1TI%3D&reserved=0
>  hasn't
> been brought up to date with DWARF5 yet. This table can be useful
> because the versions of different sections do not necessarily follow the
> major DWARF version.
>
> For example, last year I had a question from a tool author where he was
> confused by the fact that .debug_line file format was only 3 even though
> he was compiling for either DWARF4 or 5 (I don't remember) on the
> command line.
>
> While we are at it and preparing DWARF6 it would be a great hint to tool
> developers to know where they need to focus effort by keeping this table
> up to date with the evolving DWARF6.
>
> -ben
>
>
> --
> Dwarf-discuss mailing list
> Dwarf-discuss@lists.dwarfstd.org
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.dwarfstd.org%2Fmailman%2Flistinfo%2Fdwarf-discuss&data=05%7C01%7Cjdelsignore%40perforce.com%7C96ab83bfa7064925670d08db2a6079ff%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638150366099554716%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xOsZNckd2q77knyiEniL2rjAB7U%2Bgik8nvDRuDUZhRc%3D&reserved=0
>
>
> CAUTION: This email originated from outside of the organization. Do not click 
> on links or open attachments unless you recognize the sender and know the 
> content is safe.

This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

-- 
Dwarf-discuss mailing list
Dwarf-discuss@lists.dwarfstd.org
https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss

Re: [Dwarf-Discuss] data-location containing "DW_OP_push_object_address / DW_OP_deref" if the variable could be in memory or register

2021-10-27 Thread John DelSignore via Dwarf-Discuss 



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/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
One of the key concepts in the extensions, which I think addresses the problem you described, is to make locations (memory, register, composite, implicit, and undefined) first-class objects that can be pushed onto the DWARF evaluation stack. In other words,
 instead of making a location the result of an evaluation, locations can be pushed, popped, and operated on just like addresses and values in the current model. The extensions are backwards compatible with DWARF 5 and add only a handful of operators.
 I find the design and formal specification of the model quite elegant. Further, I think the extensions are generally useful, not just specific to GPUs.

The ROCGDB and TotalView debuggers have both implemented the model from the consumers' side, and the AMD HIP/LLVM compilers produces a subset of the extensions for stack unwinding. I believe that AMD is working on further modifications to support variable
 locations.
About a month ago, Tony Tye from AMD did a presentation (DWARF Extensions for Optimized SIMT/SIMD (GPU) Debugging) at the Linux Plumbers Conference 2021, GNU Tools Cauldron. The presentation is here on YouTube:
https://youtu.be/QiR0ra0ymEY?t=10040
It starts at about time 2:47:40 and is 30 minutes long. I think it does a good job at visually explaining the extensions, so you might want to watch it before reading the extensions document.

Cheers, John D.



On 10/24/21 12:58 PM, Martin via Dwarf-Discuss wrote:


The problem was already described here 
https://nam12.safelinks.protection.outlook.com/?url="">

But the replies in that thread only answered the case for DW_AT_frame_base 


However, if you have a data-type like described 

- At "Address of variable": e.g. pointer to 0x1234 
- At 0x1234: some data, e.g. a structure or array 

Note, that the address of the variable can not be 0x1234, as taking the 
address of the variable "&var" should return a pointer to the first block. 

The variable can have a DW_AT_location 
- that is an address in memory 
- the name of a register 
- a location list, that returns sometimes an address, 
  sometimes a register 

In order to access data at 0x1234, the data type would have an 
DW_AT_data_location like: 
  DW_OP_push_object_address, DW_OP_deref, ... 
(maybe followed by an adding an offset or other OPs) 

But that only works for memory locations. (at least various emails on 
the list suggest this) 


How can such a type be represented? 

Since DW_OP_push_object_address is documented 
The DW_OP_push_object_address operation pushes the address of the object

3 currently being evaluated 


it would be good if DW_OP_deref would always work. 

DW_OP_regN 
The DW_OP_reg operations encode the names of up to 32 registers,

8 numbered from 0 through 31, inclusive. The object addressed is in register n 


The last sentence can be read that this is "the address" of that register. 

If so, then maybe DW_OP_deref should be documented to fetch the value in 
the register. 

The above example also illustrates why the register-content should be 
the result of the dereferencing, as it leads to the same final address 
(and that is correct if it is the same variable to start with) 


And there is more: 
The part of the variable data that is 0x1234 could be stored across 
several registers. Then the DW_AT_location of the variable would contain 
several DW_OP_piece. 

There is an example that gives some clue what should happen, if a 
DW_AT_location returns a value like this. 
Page 291 (Dwarf 5) 
DW_OP_lit1 DW_OP_stack_value DW_OP_piece 4 DW_OP_breg3 0 DW_OP_breg4 0

1110 DW_OP_plus DW_OP_stack_value DW_OP_piece 4 
The object value is found in an anonymous (virtual) location 


So DW_OP_piece also returns a location (albeit a virtual one). That 
could then also be dereferenced by DW_OP_deref (or maybe it already can?). 

IMHO, that should be explicitly clarified. Or alternatives should be given. 


** Actual real world example. 

FPC (Free Pascal) has several types, that have such an hidden pointer. 
(AnsiString (array of char), dynamic array, objects) 

The "pointer part" is being passed around as the variable (e.g. as a 
function parameter, or on assignment). 
All variables that have the same value in the "pointer part" share the 
same data in the "pointed to part". 

So the pointer-part could be ending up in a register. But the type must 
still be able to describe the data location. 
___ 
Dwarf-Discuss mailing list 
Dwarf-Discuss@lists.dwarfstd.org

https://nam12.safelinks.protection.outlook.com/?url="">



CAUTION: This email originated from outside of the organization. Do not click on links or open attachments unless you recog

[Dwarf-Discuss] Do any of the Intel compilers still generate DW_OP_INTEL_bit_piece=0xe8?

2021-05-06 Thread John DelSignore via Dwarf-Discuss 
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 compiler to TotalView. 
The Intel 9.0.022 compiler generated DW_OP_INTEL_bit_piece when compiling in 
bi-endian mode. In 2009, John Bishop posted the following message: 
.
 So, it appears as if the answer is "no", and it should be safe to assume that 
DW_OP_INTEL_bit_piece is no longer generated by any Intel compiler.

The reason I ask is that the "AMD GPU DWARF extensions for heterogeneous 
debugging" defines DW_OP_LLVM_aspace_bregx=0xe8, which conflicts with 
DW_OP_INTEL_bit_piece.

So, is it safe to remove DW_OP_INTEL_bit_piece and assume that all recent 
(within the last 10 years) Intel compilers now use DW_OP_bit_piece? Or do I 
need to interpret opcode 0xe8 as DW_OP_INTEL_bit_piece when the compilation 
unit's producer smells like an old-ish Intel compiler?

Thanks, John D.



This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] DW_AT values unknown to me.

2021-02-17 Thread John DelSignore via Dwarf-Discuss 
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.

Cheers, John D.

On 2/17/21 6:07 PM, David Anderson via Dwarf-Discuss wrote:
> I try to make the dwarf.h  file complete in its set of DW_AT values,
> including non-standard entries I know nothing about.
>
> I recently came across a few whose proper spelling is
> completely unknown to me. So I made up names.
> Browser searches revealed nothing so far.
>
> /*  From DWARF2 DW_AT_producer GHS C 2012.5.4 [dual] */
> #define DW_AT_GHS_unknown1 0x2083
> #define DW_AT_GHS_unknown2 0x2087
> #define DW_AT_GHS_unknown3 0x2085
> #define DW_AT_GHS_unknown4 0x2086
> #define DW_AT_GHS_unknown5 0x2092
>
> If anyone can come up with the proper spellings and let me know
> what those are I would appreciate it.
>
> Thanks in advance.
> David Anderson (libdwarf)
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>
> CAUTION: This email originated from outside of the organization. Do not click 
> on links or open attachments unless you recognize the sender and know the 
> content is safe.

This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] Callable interface for Fortran "coarray" features

2020-12-30 Thread John DelSignore via Dwarf-Discuss 



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 likely a debugger) how to call out to a helper library to satisfy the queries.
Tony can explain better than I, but basically it's a generalization and abstraction of existing models where the semantics and interfaces are hard-coded into the tools. For example, for TLS (thread-local storage) on Linux, DWARF has "push TLS" operators
 where the debugger is supposed to know to dlopen() and call into libthread_db.so to calculate the address of a TLS object given the "key" on the top of the evaluation stack. The vision is to enhance DWARF to be able to describe complex operations without hard-coding
 the details of the interface into the tools.
Cheers, John D.

On 12/28/20 2:52 PM, Bishop, John E via Dwarf-Discuss wrote:





This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.



___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] modeling different address spaces

2020-07-16 Thread John DelSignore via Dwarf-Discuss 
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 be push onto the 
evaluation stack.

https://llvm.org/docs/AMDGPUDwarfProposalForHeterogeneousDebugging.html

AFAIK, these changes will be made to LLVM and there is interest in adding to 
the DWARF standard eventually.

Cheers, John D.

On 2020-07-16 13:06, Todd Allen via Dwarf-Discuss wrote:
> Markus, Michael, David, Xing,
>
> I always assumed that the segment support in DWARF was meant to be more 
> general,
> and support architectures where there was no single flat memory, and so the
> segments were necessary for memory accesses.  I personally have not dealt with
> any architectures where DW_AT_segment came into play, though.
>
> Certainly x86 does not fall into that "truly distinct segments" category, at
> least not in modern times.  The segment registers there (fs & gs, for example)
> are an indirect way of specifying a base address within the flat address 
> space.
> They usually end up being used for thread-specific data structures where each
> thread has a different segment selector which implies a different base 
> address.
> And it requires a syscall to interact with the base addresses, at least on
> Linux.  The other segment registers (cs, ds, ss) are set-and-forget by the OS
> typically.
>
> The CUDA architecture is an interesting case.  It doesn't use DW_AT_segment at
> all.  But it does use the DW_AT_address_class attribute to specify CUDA 
> segments
> (e.g. Global, Local, Shared, among many others) for variables and/or types.  
> So
> it's fairly fine-grained.  You can, for example, have a shared pointer to a
> global pointer to a local integer, and the DW_AT_address_class attribute can
> convey that.
>
> Some of those CUDA segments are for radically different sorts of memory
> (e.g. very low latency Shared memory vs. high latency Global memory).  But 
> other
> distinctions seem more gratuitous (e.g. Param vs. Global memory).  I assume 
> that
> there's a CUDA under-the-hood mapping of many of the segments to regions of a
> flat Global address space in there, but the CUDA architectures & drivers
> deliberately hide that mapping.  So effectively you end up with all the 
> segments
> being distinct, as far as a debugger can tell.
>
> On Thu, Jul 16, 2020 at 09:23:51AM +, Dwarf Discussion wrote:
>>Hello,
>>
>>
>>
>>What would be the recommended way to model variables that are allocated to
>>different address spaces?
>>
>>
>>
>>I found DW_OPT_xderef for dereferencing address-space qualified pointers
>>but the resulting memory location description wouldn't have an
>>address-space qualifier.
>>
>>
>>
>>I found DW_AT_address_class, which allows attaching an integer, which
>>could represent the address-space.  This sounds pretty close.  I'm a bit
>>thrown off by the example, though.
>>
>>
>>
>>Thanks,
>>
>>Markus.
>>
> --
> Todd Allen
> Concurrent Real-Time
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>
> CAUTION: This email originated from outside of the organization. Do not click 
> on links or open attachments unless you recognize the sender and know the 
> content is safe.

This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Re: [Dwarf-Discuss] DWARF dumpers should note compressed sections

2018-08-03 Thread John DelSignore via Dwarf-Discuss 
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 compressed was that the 
SHF_COMPRESSED flag was set in the section header.  We had been handling that 
in executable and shared library files, but not the .dwo files.

Cheers, John D.


On 08/03/18 10:59, Paul Robinson via Dwarf-Discuss wrote:
> Recently somebody was poking around looking at compressed DWARF sections,
> and observed that some tools (dwarfdump, objdump, readelf) were dumping
> them just fine, but without any indication that the original section was
> compressed (citing ELF flag SHF_COMPRESSED).  If anybody on this list
> happens to be a maintainer of a DWARF dumper :0) they might want to take
> a look at reporting this tidbit.
>
> I know that some toolchains prefix a compressed section name with "z"
> (e.g., .zdebug_info) but I wasn't aware of the ELF section flag.
> --paulr
>
> ___
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>

___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org