Skip to content

symbol names: keep using . on non-Apple unix systems #14143

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: trunk
Choose a base branch
from

Conversation

Octachron
Copy link
Member

As discussed in #14104, this PR proposes to revert to using . as module separator for symbol names on non-Apple unix systems — at the very least for OCaml 5.4.

This should restore the support of OCaml symbol name mangling in perf for OCaml 5.4, while keeping the lldb fix on Apple systems . Moreover, it seems likely to me that any tools analyzing symbol names already needs to have OS specific paths, thus we are hopefully not exporting a noticeable amount of complexity to those external tools.

cc @tmcgilchrist

@@ -7,4 +7,4 @@ ${program}

# now check the assembly file produced during compilation
asm=${test_build_directory}/func_sections.s
grep "\.section \.text\.caml\.camlFunc_sections\\$" "$asm" | wc -l | tr -d ' ' | sed '/^$/d'
grep "\.section \.text\.caml\.camlFunc_sections." "$asm" | wc -l | tr -d ' ' | sed '/^$/d'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using just . matches any character. I'm not sure this is what you had in mind. Maybe something like that instead?

Suggested change
grep "\.section \.text\.caml\.camlFunc_sections." "$asm" | wc -l | tr -d ' ' | sed '/^$/d'
grep "\.section \.text\.caml\.camlFunc_sections[.$]" "$asm" | wc -l | tr -d ' ' | sed '/^$/d'

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was a quick fix, but yes I agree it is better to narrow this grep.

Changes Outdated
* #13050: Use '$' instead of '.' to separate module names in symbol names.
This changes mangling of OCaml identifiers from
* #13050, #14104, #?????: Use '$' instead of '.' to separate module names
in symbol names on Apple and non-unix operating systems.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think being more explicit about which platforms are affected would be a bit nicer:

Suggested change
in symbol names on Apple and non-unix operating systems.
in symbol names on macOS and Windows (including the Cygwin backend).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is also slightly more correct since with the current code any new operating system will end up using . as a symbol name separator.

Copy link
Contributor

@xavierleroy xavierleroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Thanks! There may be some issues with a couple of tests, see below. Make sure to run a Jenkins CI precheck test.

Comment on lines +12 to +13
(lldb) create camlMeander[.$]c_to_ocaml*
Breakpoint created for regex camlMeander[.$]c_to_ocaml*.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks wrong. Keep using \$ ?

Copy link
Member Author

@Octachron Octachron Jul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the [.$] regexp allows to keep the same lldb script on all platforms. Otherwise, we would need to have a lldb-linux-script and a lldb-script. The quirky regexp seemed better to me than the duplication.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... the file name says it's a reference file and it is for macos. There is also a linux-lldb-arm64.reference in the same directory. Not sure how to reconcile this with your reply.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests are sharing the same debugger script:

   debugger_script = "${test_source_directory}/lldb-script";

and it is this script which is echoed inside the reference file.

Comment on lines +12 to +13
(lldb) create camlMeander[.$]c_to_ocaml*
Breakpoint created for regex camlMeander[.$]c_to_ocaml*.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment.

Comment on lines +6 to +7
"camlCmm.5":
addr "camlCmm.standard_atomic_get_274"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to make sure that this test is not run on macOS and Windows. For the record: I thoroughly dislike tests that match on dumps of internal compiler passes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test is even more restricted than that: it is restricted to linux, amd64, no flambda and no-tsan .

@@ -56,6 +56,9 @@ val current_unit_symbol: unit -> Symbol.t
val symbol_separator: char
(* Return the module separator used when building symbol names. *)

val escape_prefix: string
(* Return the escape prefix for hexadecimal escape sequence. *)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps, to be extra clear:

Suggested change
(* Return the escape prefix for hexadecimal escape sequence. *)
(* Return the escape prefix for hexadecimal escape sequences in symbol names. *)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants