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

[Adrian Prantl]

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 <JDelSignore@perforce.com> 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 <compilation-directory><random-control-character><directory-path-of-file-name>
> N_SO <basename-of-file-name>
> 
> 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 '
> 0000000000000000 - 01 0000    SO 
> 0000000000000000 - 00 0000    SO /tmp/^L/nfs/homes/jdelsign/
> 0000000000000000 - 00 0000    SO hello.c
> 0000000000000000 - 01 0000    SO 
> 0000000000000000 - 00 0000    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/
> 0000000000000000 - 00 0000    SO emutls.c
> 0000000000000000 - 01 0000    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.
> 
> 

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