Skip to content
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

Does not support Apple Silicon #477

Open
yaroslavyaroslav opened this issue Nov 18, 2022 · 10 comments
Open

Does not support Apple Silicon #477

yaroslavyaroslav opened this issue Nov 18, 2022 · 10 comments

Comments

@yaroslavyaroslav
Copy link
Contributor

It fails to build because of there's no build case for Apple silicon.

make
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -c -O3 -mtune=native -funroll-loops -std=c11 -I/usr/local/include -D_GNU_SOURCE -Wall -Wextra -Werror -Wno-format-truncation -Wno-override-init -I. -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk -x objective-c -pedantic -fblocks -Wno-unused-parameter -Wimplicit -Wunused -Wcomment -Wchar-subscripts -Wuninitialized -Wreturn-type -Wpointer-arith -Wno-gnu-case-range -Wno-gnu-designator -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-attributes -Wno-embedded-directive -Wno-initializer-overrides -Wno-unknown-warning-option -Wno-gnu-empty-initializer -Wno-format-pedantic -Wno-gnu-statement-expression -mllvm -inline-threshold=2000 -D_HF_ARCH_DARWIN -fblocks -o mac/arch.o mac/arch.c
mac/arch.c:699:5: error: unknown type name 'x86_thread_state_t'; did you mean 'arm_thread_state_t'?
    x86_thread_state_t* platform_in_state = ((x86_thread_state_t*)(void*)in_state);
    ^~~~~~~~~~~~~~~~~~
    arm_thread_state_t
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk/usr/include/mach/arm/thread_status.h:101:36: note: 'arm_thread_state_t' declared here
typedef _STRUCT_ARM_THREAD_STATE   arm_thread_state_t;
                                   ^
mac/arch.c:699:66: error: expected expression
    x86_thread_state_t* platform_in_state = ((x86_thread_state_t*)(void*)in_state);
                                                                 ^
mac/arch.c:699:47: error: use of undeclared identifier 'x86_thread_state_t'
    x86_thread_state_t* platform_in_state = ((x86_thread_state_t*)(void*)in_state);
                                              ^
mac/arch.c:699:68: error: expected expression
    x86_thread_state_t* platform_in_state = ((x86_thread_state_t*)(void*)in_state);
                                                                   ^
mac/arch.c:701:50: error: no member named 'tsh' in 'struct __darwin_arm_thread_state'
    if (x86_THREAD_STATE32 == platform_in_state->tsh.flavor) {
                              ~~~~~~~~~~~~~~~~~  ^
mac/arch.c:701:9: error: use of undeclared identifier 'x86_THREAD_STATE32'
    if (x86_THREAD_STATE32 == platform_in_state->tsh.flavor) {
        ^
mac/arch.c:702:38: error: no member named 'uts' in 'struct __darwin_arm_thread_state'
        run->pc = platform_in_state->uts.ts32.__eip;
                  ~~~~~~~~~~~~~~~~~  ^
mac/arch.c:704:38: error: no member named 'uts' in 'struct __darwin_arm_thread_state'
        run->pc = platform_in_state->uts.ts64.__rip;
                  ~~~~~~~~~~~~~~~~~  ^
8 errors generated.
make: *** [mac/arch.o] Error 1
@robertswiecki
Copy link
Collaborator

I think this code is used for getting instruction pointer. If your C-fu is strong enough, I'd suggest surrounding it with ifdef's for given CPU arch, like here

https://github.com/google/honggfuzz/blob/master/linux/trace.c#L80

and send me a PR with correct code?

@yaroslavyaroslav
Copy link
Contributor Author

Well my C-fu is quite opposite, actually, but I guess this one I could have handled with some time. For now (totally noob about this codebase) this kind of work looks more boilerplate rather than the one that requires any deep knowledge about that.

@devnexen
Copy link
Contributor

I think this code is used for getting instruction pointer. If your C-fu is strong enough, I'd suggest surrounding it with ifdef's for given CPU arch, like here

https://github.com/google/honggfuzz/blob/master/linux/trace.c#L80

There is that but ultimately there is also the fact that CrashReport* binaries are for x86 arch ?

@robertswiecki
Copy link
Collaborator

Yeah, I don't know where to get aarch64 crashwrangler libs - I merely compile it on some mac to verify that it builds, I'm not sure how it exactly works.

FWIW I added code here d9e70de - but one will have to find relevant lib and put it here https://github.com/google/honggfuzz/tree/master/third_party/mac for it to compile

@awakened1712
Copy link

Yeah, I don't know where to get aarch64 crashwrangler libs - I merely compile it on some mac to verify that it builds, I'm not sure how it exactly works.

FWIW I added code here d9e70de - but one will have to find relevant lib and put it here https://github.com/google/honggfuzz/tree/master/third_party/mac for it to compile

Any updates? Do we have a new crashwrangler?

@devnexen
Copy link
Contributor

devnexen commented Feb 3, 2023

in the "old days" there was the crashwrangler source code if you had a apple license seems no longer the case (I might be wrong) to be able to provide the object file but I would not be surprised if it did not compile on arm64 (again can be wrong here), maybe in the long run the solution is to find a replacement.

@robertswiecki
Copy link
Collaborator

Could POSIX code work instead?

OS=POSIX make clean all

??

@devnexen
Copy link
Contributor

wish it did but there is no such timer_t type in macOs.

@robertswiecki
Copy link
Collaborator

I don't think it was used anywhere? Please try at HEAD, I removed it with 2880d45

@devnexen
Copy link
Contributor

another failure, libhfcommon/util.c <link.h> header does not exist. I ll see at some point if it s doable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants