MacOS support

[SickleFire]

Problem

A core pillar of the m-vis design philosophy is providing a simple, fast memory visualizer that "works everywhere".

omitting macOS leaves out a massive segment of software engineers and security researchers who use Apple Silicon or Intel-based Macs as their primary development environments. To fulfill our mission of cross-platform parity, native macOS support is a vital next step.

Proposed Solution

We should introduce a third platform-dispatch module under src/stack_trace/ and src/os/ specifically targeting target_os = "apple-darwin"

We also have to consider what architecture should we support, such as Intel based macs or apple silicon macs. this will not be an easy task.

The implementation should mirror our existing async TUI/CLI architecture:

• Process & Region Walking
• Stack Unwinding

Examples

• Cross-Platform Devs: A software engineer developing a cross-platform Rust or C++ application can use the exact same TUI interface on their MacBook during a commute as they do on their Linux workstation or Windows PC.

[Samanyu-dev]

Hi @SickleFire, I am back... I didnt see this issue last time. I own and work on a Mac, can I work on this? need little bit more on what to do like a checklist if you want me to work on this
Thankyou :)

[SickleFire]

Hi @SickleFire, I am back... I didnt see this issue last time. I own and work on a Mac, can I work on this? need little bit more on what to do like a checklist if you want me to work on this
Thankyou :)

Hey @Samanyu-dev welcome back!

You're the perfect person to work on this.

Because of the new MemoryProvider trait. your own implementation of the macos.rs file should fulfill the those trait of a MemoryProvider and it should work theoretically.

• implement walk_regions
• implement walk_heap
• implement list_modules

See types.rs—Basically MemoryProvider turns platform specific data into our platform-agnostic data, which in turn what core uses.

I don't know the details of implementing this traits in macOS (mach kernel APIs?) But I believe you can handle this task.

Thank you so much!

[Samanyu-dev]

Ok will work on this tonight, will first research about what's needed and then implement them. Will see ya with the updated tomorrow IST

[Samanyu-dev]

Hey @SickleFire, could you share a few validation scenarios or expected outputs that I can use to verify the implementation?

[SickleFire]

@Samanyu-dev here is some expected outputs on windows,

-a uses walk_regions
-h uses walk_heap
modules uses list_modules

scan notepad.exe -a

scan notepad.exe -h

modules notepad.exe -t

[Samanyu-dev]

Hi, I have been trying to work it out, but you know of apple's protection. The tui is working well with scan command and list command. Will try to figure out the breakthrough with the protection. Would you like me to raise a PR with whatever has been done so far?

[SickleFire]

Hey @Samanyu-dev thank you for your efforts, yes you can send me a PR, and we'll figure out how to fix Apple's protection.

Thanks!

[Samanyu-dev]

Hey @SickleFire, any improvements to be done?

[SickleFire]

Hey @Samanyu-dev! Thanks so much for asking, and incredible work getting the macOS support completed.

Right now, my plan is to push your changes into our upcoming v0.4.0-rc1 very soon(June 20). Once it's in the RC, we are going to do a call for testers on Reddit to get a bunch of different Mac users to stress-test it for runtime edge cases. I'll keep you posted!

I will close this issue once v0.4.0 stable releases (July 3).

Many thanks!

[Samanyu-dev]

will look forward to test results!