Conversation
|
issue with clang format , and where is the CI action?:D |
ci for freebsd is a can of worms i dont think we should open, and with we i mean I |
|
co-pilot gave me this : ` freebsd-sdl: ` |
copilot, is, respectfully, stupid remember freebsd is ran on a vm with libvirt within a github runner i think there are like 2-3 shadPS4 users who use freebsd, either way maintaining freebsd support isn't that hard, just dont use linux-isms (basically like it was |
CMakeLists.txt
Outdated
| find_package(Zydis 5.0.0 CONFIG) | ||
| # Outdated zydis from ports | ||
| if (NOT ${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD") | ||
| find_package(Zydis 5.0.0 CONFIG) |
There was a problem hiding this comment.
Why is this needed? If the version in FreeBSD is outdated we should be using the submodule.
There was a problem hiding this comment.
zydis will get updated soon so it wont matter in a few days
There was a problem hiding this comment.
I just received info that zydis wont be updated till someone sends a new patch and that patch gets merged
which basically translates into eternity, i'll make it use submodules
Oh yeah one small issue through, find_package(Zydis 5.0.0 CONFIG) was suceeding even through zydis was NOT 5.0.0, it's 4.1.1 in FBSD ports - don't know why yet
|
|
||
| if (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD") | ||
| target_link_libraries(shadps4 PRIVATE "/usr/lib/libusb.so") | ||
| target_link_libraries(shadps4 PRIVATE "/usr/local/lib/libuuid.so") |
There was a problem hiding this comment.
Why do we need to do this? Rather would not hard code library paths.
There was a problem hiding this comment.
default cmake doesnt play nicely with some FreeBSD configs
There was a problem hiding this comment.
Well it would be nice if we could at least find_library or something as an alternative instead of hardcoding paths
| add_subdirectory(ext-libusb) | ||
| add_library(libusb::usb ALIAS usb-1.0) | ||
| if (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD") | ||
| # YOU MUST USE NATIVE LIBUSB |
There was a problem hiding this comment.
We cannot use native libusb as it does not enforce our ABI requirements to match callbacks from PS4 applications.
There was a problem hiding this comment.
there's no libusb port for freebsd - only the native libusb from fbsd itself
There was a problem hiding this comment.
Well I don't think this will work since the guest callback ABI likely won't match host, if libusb doesn't work as a submodule we would probably just need to disable it for FreeBSD.
| } | ||
| shm_unlink(shm_path.c_str()); | ||
| #elif defined(__FreeBSD__) | ||
| backing_fd = memfd_create("BackingDmem", 0); |
There was a problem hiding this comment.
Think you should just ifdef the madvise and leave the rest as common since its the same.
| } | ||
| return false; | ||
| #elif defined(__FreeBSD__) | ||
| return false; |
There was a problem hiding this comment.
the "normal way" to do these things is via dtrace but the easiest way to find if there is dtrace, is to literally do:
system("pgrep dtrace")and get the result code...
i mean there is also lldb/gdb but pragmatically it would mean making a gdb server and seeing if there is a gdb instance hooked up and lots of annoying details
adds freebsd support