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

[John DelSignore]

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:

0003220    2       -   g   d   w   a   r   f   -   4  \0  \f   /   n   f
0003240    s   /   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 aprantl@apple.com<mailto:aprantl@apple.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

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

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