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