Add FreeBSD x86_64 debug tests

[XVilka]

Your checklist for this pull request

• [x] I've read the guidelines for contributing to this repository
• [x] I made sure to follow the project's coding style
• [ ] I've documented or updated the documentation of every function and struct this PR changes. If not so I've explained why.
• [x] I've added tests that prove my fix is effective or that my feature works (if possible)
• [ ] I've updated the rizin book with the relevant information (if needed)

Detailed description

Adds basic FreeBSD x86_64 debug tests.

Requires https://github.com/rizinorg/rizin-testbins/pull/101

Test plan

FreeBSD CI is green

Closing issues

Partially addresses https://github.com/rizinorg/rizin/issues/3072

[XVilka]

@arrowd, you might be interested in this one, by the way. Feel free to send a new PR if you want.

[XVilka]

@kazarmy as you can see, even FreeBSD debugging doesn't work:

[XX] db/archos/freebsd-x64/dbg write gpr
RZ_NOPLUGINS=1 /home/build/bin/rizin -escr.utf8=0 -escr.color=0 -escr.interactive=0 -eflirt.sigdb.load.system=false -eflirt.sigdb.load.home=false -N -d -qc 'db @ main + 64
dc
dr rax
dr rax = 1337
dc
' bins/elf/calculate-freebsd-x64
-- stdout
--- expected
+++ actual
@@ -1,2 +1,2 @@
-rax = 0x000000000000002a
-Result = 1337
+Result = 42
+Debugging is not enabled. Run ood?

-- stderr
--- expected
+++ actual
@@ -1,4 +1,27 @@
-hit breakpoint at: f70
+Process 
+with 
+PID 
+387 
+child 
+exited 
+with 
+status 
+Process 
+finished
 
-Process finished
 
+ERROR: 
+Failed 
+to 
+read 
+ERROR: 
+No 
+such 
+register 
+or 
+register 
+type: 
+ERROR: 
+Failed 
+to 

https://builds.sr.ht/~thestr4ng3r/job/1239045

[kazarmy]

Well that's one reason why no testing was done in #4524 - debugging might have been broken well before the build itself broke

[well-mannered-goat]

Wrote some changes description in the PR

Also in FreeBSD sysctl is used to fetch maps first, because procfs is not mounted on \proc\ hence no pid directories are there by default. Also the parsing logic is kind of flawed because of different map format (after mounting procfs) They aren't fetched from /proc/ (its the second option if sysctl does not work), so I thought this is redundant code and with bugs. Should I remove it?

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 44.56%. Comparing base (362bac1) to head (d9ea687). Report is 1 commits behind head on dev.

Additional details and impacted files

Files with missing lines	Coverage Δ
librz/core/cfile.c	47.26% <ø> (ø)

... and 10 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 362bac1...d9ea687. Read the comment docs.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[notxvilka]

Wrote some changes description in the PR

Also in FreeBSD sysctl is used to fetch maps first, because procfs is not mounted on \proc\ hence no pid directories are there by default. Also the parsing logic is kind of flawed because of different map format (after mounting procfs) They aren't fetched from /proc/ (its the second option if sysctl does not work), so I thought this is redundant code and with bugs. Should I remove it?

It's better to keep but open an issue about it, then we can decide what to do with it in a separate PR.

[well-mannered-goat]

Forgot about the step over test, will also add it

[well-mannered-goat]

Wrote some changes description in the PR Also in FreeBSD sysctl is used to fetch maps first, because procfs is not mounted on \proc\ hence no pid directories are there by default. Also the parsing logic is kind of flawed because of different map format (after mounting procfs) They aren't fetched from /proc/ (its the second option if sysctl does not work), so I thought this is redundant code and with bugs. Should I remove it?

It's better to keep but open an issue about it, then we can decide what to do with it in a separate PR.

I'll just open up an issue then.