subject:"Re\: \[Dwarf\-discuss\] gfortran \/ gcc on Mac puts control characters in N

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

2024-03-15 Thread Jakub Jelinek via Dwarf-discuss

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 supports
mergeable sections or if a string is used more than once in the debug info
and user has not requested otherwise (-fno-merge-debug-strings).
I bet Darwin doesn't have ELF style SHF_MERGE | SHF_STRINGS support, and
looking on godbolt at clang --target=x86_64-darwin -S -gdwarf-4 output
I don't see that it would be trying to mark the __debug_str section
in some special way.
So, does Darwin linker merge the __debug_str strings anyway even when the 
section
isn't specially marked for it?
In any case, DW_FORM_string is a valid DWARF form...

Jakub

-- 
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

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 

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 Adrian Prantl via Dwarf-discuss

> On Mar 15, 2024, at 9:22 AM, John DelSignore via Dwarf-discuss 
>  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

-- 
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

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 Adrian Prantl via Dwarf-discuss

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.
> 
> 

-- 
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,

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

For example:

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:

> 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-14 Thread Adrian Prantl via Dwarf-discuss

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


-- 
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_unwind -rpath /opt/local/lib/libgcc 
-rpath @loader_path -rpath 
/opt/local/lib/gcc13/gcc/x86_64-apple-darwin23/13.2.0 -rpath 
/opt/local/lib/gcc13

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

2024-03-13 Thread Jakub Jelinek via Dwarf-discuss

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?
Do you see it in gfortran-mp-13 -gdwarf-4 -S output?
Or in the object file with -c?  Then it could be introduced by the
assembler.
Or it could be introduced by the linker or by other tools (dsymutil?).

If you think it is a gfortran bug, please file a bug about it in
https://gcc.gnu.org/bugzilla/ , I know next to nothing about Darwin and
would strongly prefer not to learn anything further about it.

Jakub

-- 
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

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

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

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

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

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

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

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

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

9 matches

Site Navigation

Mail list logo

Footer information