-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
base: trunk
Are you sure you want to change the base?
Conversation
@@ -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' |
There was a problem hiding this comment.
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?
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' |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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:
in symbol names on Apple and non-unix operating systems. | |
in symbol names on macOS and Windows (including the Cygwin backend). |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
(lldb) create camlMeander[.$]c_to_ocaml* | ||
Breakpoint created for regex camlMeander[.$]c_to_ocaml*. |
There was a problem hiding this comment.
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 \$
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
(lldb) create camlMeander[.$]c_to_ocaml* | ||
Breakpoint created for regex camlMeander[.$]c_to_ocaml*. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment.
"camlCmm.5": | ||
addr "camlCmm.standard_atomic_get_274" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. *) |
There was a problem hiding this comment.
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:
(* Return the escape prefix for hexadecimal escape sequence. *) | |
(* Return the escape prefix for hexadecimal escape sequences in symbol names. *) |
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