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

[John DelSignore]

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 +0000, 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
00000000000000a0 s lC0
00000000000000cb s lC1
0000000000000150 s EH_frame1
00000000000000e0 D ___emutls_v.ticker
0000000000000000 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
0000000000000000 - 00 0000    SO /nfs/homes/jdelsign/^L/nfs/homes/jdelsign/
0000000065f21d4e - 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
dc3-mac-tvt4 234 03/13 18:06 ~ %

If I add -Wl,-debug to the link command, it looks like it ends up invoking the following:

/opt/local/bin/ld-classic -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

So, it must be something /opt/local/bin/ld-classic is doing. In fact, there's evidence that ld is reading the DWARF, probably to build the Mach-O index, because it chokes on DWARF 5:

dc3-mac-tvt4 238 03/13 18:16 ~ % gcc-mp-13 -gdwarf-5 hello.c
ld: warning: can't parse dwarf compilation unit info in /var/folders/6q/3958kh1s4mjbpcdt5nhlcnmm0017hg/T//ccPKNsmu.o
dc3-mac-tvt4 239 03/13 18:16 ~ %

I'm not sure where /opt/local/bin/ld-classic comes from, but it's a script that invokes the Apple / LLVM linker:

dc3-mac-tvt4 245 03/13 18:21 ~ % sh -v /opt/local/bin/ld-classic -v
#!/bin/bash

if [[ -x /usr/bin/xcrun ]] ; then
    exec /usr/bin/xcrun ld -ld_classic "${@}"
elif [[ -x /usr/bin/ld ]] ; then
    exec /usr/bin/ld -ld_classic "${@}"
else
    exec ld -ld_classic "${@}"
fi
@(#)PROGRAM:ld-classic  PROJECT:ld64-907
BUILD 12:59:46 Nov 10 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.8)
dc3-mac-tvt4 246 03/13 18:21 ~ %

I wonder if anyone at Apple / LLVM cares about gfortran / gcc.

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:

dc3-mac-tvt4 253 03/13 18:24 /tmp % cc -o hello ~/hello.c -gdwarf-4
dc3-mac-tvt4 254 03/13 18:24 /tmp % nm -ap hello | grep ' SO '
0000000000000000 - 01 0000    SO
0000000000000000 - 00 0000    SO /nfs/homes/jdelsign/
0000000000000000 - 00 0000    SO hello.c
0000000000000000 - 01 0000    SO
dc3-mac-tvt4 255 03/13 18:25 /tmp %

Even though the DWARF has the DW_AT_comp_dir attribute:

0x0000000b: DW_TAG_compile_unit
              DW_AT_producer   ("Apple clang version 15.0.0 (clang-1500.1.0.2.5)")
              DW_AT_language   (DW_LANG_C99)
              DW_AT_name       ("/nfs/homes/jdelsign/hello.c")
              DW_AT_LLVM_sysroot       ("/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk")
              DW_AT_APPLE_sdk  ("MacOSX.sdk")
              DW_AT_stmt_list  (0x00000000)
              DW_AT_comp_dir   ("/tmp")
              DW_AT_low_pc     (0x0000000100003ec0)
              DW_AT_high_pc    (0x0000000100003f56)

Perhaps there's some nuance in the way gcc / gfortran generate the DWARF that confuses the linker?

If you think it is a gfortran bug, please file a bug about it in
...snip..., I know next to nothing about Darwin and
would strongly prefer not to learn anything further about it.

I can't say I blame you!

Cheers, John D.



        Jakub



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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dwarfstd.org/pipermail/dwarf-discuss/attachments/20240313/3ecc86bf/attachment-0001.htm>