Fix Issue 19593 - use memcmp instead of dstrcmp

[kubo39]

Using dstrcmp inside trace_addsym causes stack overflow, because dmd
inserts trace_pro function to top of dstrcmp when -profile option is added.

[dlang-bot]

Thanks for your pull request and interest in making D better, @kubo39! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	19593	minor	dstrcmp with -profile causes stack overflow

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + druntime#2467"

[rainers]

I assume you are not recompiling the runtime with -profile, but that the issue is that rt.trace and your code reference the same symbol dstrcmp, but also generate different implementations. The linker picks the one with profiling hooks causing the stack overflow in the profiler code.

Please also remove the respective import.

[rainers]

There seem to be other changes to the profile.log, too:

diff mytrace.def.exp ./generated/linux/debug/64/mytrace.def
3c3
< _D4core8internal6string__T7dstrcmpZQjFNaNbNiNeMxAaMxQeZi
---
> _D6object__T5__cmpTaZQjFNaNbNiNeMxAaMxQeZi
4a5
> _D4core8internal6string__T7dstrcmpZQjFNaNbNiNeMxAaMxQeZi
Makefile:13: recipe for target 'generated/linux/debug/64/profile.done' failed```

[kubo39]

I assume you are not recompiling the runtime with -profile, but that the issue is that rt.trace and your code reference the same symbol dstrcmp, but also generate different implementations. The linker picks the one with profiling hooks causing the stack overflow in the profiler code.

Ah, yes, I found this at FuncDeclaration__toObjFile in dmd/src/dmd/glue.d (sorry for my poor english..)

[n8sh]

LGTM