assorted fixes for powerpc-apple-darwin9#4
assorted fixes for powerpc-apple-darwin9#4grobian wants to merge 26 commits intoiains:darwin-xtools-2-2-4from
Conversation
XTOOLS_TAPI_SUPPORT is set accordingly, but the code unconditionally required TAPI. Added some guards to disable TAPI bits in the code when XTOOL_TAPI_SUPPORT is OFF. Hide the TAPI bits in Options, stub entire textstub_dylib_file when TAPI is not supported. Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Fix warning ../darwin-xtools/ld64/src/other/unwinddump.cpp:1174:6: error: ‘exit’ was not declared in this scope; did you mean ‘_exit’? Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
At least GCC (10.1.0) defines PPC by default on powerpc-apple-darwin9, e.g. it would result in both I386 and PPC being defined, which is resulting in compilation problems. Undefine PPC to ensure only the approprate target code is enabled. Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
We currently don't install libs, so referencing libprunetrie.dylib from strip is bound to result in a trap. Since I can't see a reason to distribute libprunetrie, and ld(64) seems to incorporate it as well, just statically link strip against libprunetrie. Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
darwin 20 _mcontext.h references this struct, so provide its definition Signed-off-by: Fabian Groffen <grobian@gentoo.org>
TAPI is a project with close ties to LLVM, which means one needs it to build a linker. On systems where no LLVM is used (like older Darwin), or systems where GCC is in use instead, this means TAPI cannot be built. On recent Darwin systems, a linker that does not do TAPI, cannot do much, since all system libraries are .tbd (TAPI stubs). Hence, to e.g. bootstrap LLVM, we need to be able to build a linker that understands TAPI, without having TAPI (the host may not supply it either). This introduces TAPIlite, an implementation of those classes ld64 uses, with help of libyaml. This is very limited at this point, and whether or not it works is very brittle. Further development here is likely necessary. Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
- support multiple (inlined) documents - simplify strategy of preferring real dylibs over text stubs - parsing and interpretation fixes Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
This reverts commit 102a254. Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
On Gentoo Prefix we want to specify the location of the as implementations, and not use clang, but host as (which is whatever is necessary wrapper program). Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Based on original path by Tee KOBAYASHI, which was based on work from https://trac.macports.org/ticket/63221 Adapted to be conditional, that is, only defined when not yet defined. Signed-off-by: Fabian Groffen <grobian@gentoo.org>
…ode.c.
On macOS 13, Gentoo Prefix fails to compile cctools due to
missing Blocks support in GCC, creating the following error:
/Users/ec2-user/gentoo/MacOSX.sdk/usr/include/objc/runtime.h:373:29: error: expected ')' before '^' token
373 | void (^ _Nonnull block)(Class _Nonnull aClass, BOOL * _Nonnull stop)
| ^
| )
Fortunately the header objc-runtime.h is not strictly necessary.
As a workaround, stop including objc-runtime.h in print_objc.c
and print_bitcode.c.
Signed-off-by: Yifeng Li <tomli@tomli.me>
In ar(1), strcmp() checks are used to determine the value of argument argv[1], even when no argument is given. In the past, they were possibly harmless out-of-bound reads and comparison with garbage, without consequences. However, running it on macOS 13 w/ Apple Silicon immediately crashes it with Segmentation Fault, because argv[1] is now NULL and generates EXC_BAD_ACCESS in strcmp(). This commit checks whether argc is equal or greater than 2 before doing strcmp(). $ ./bin/ar Segmentation fault: 11 * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0000000193181460 libsystem_platform.dylib`_platform_strcmp + 144 libsystem_platform.dylib`: -> 0x193181460 <+144>: ldr q0, [x0], #0x10 0x193181464 <+148>: ldr q1, [x1], #0x10 0x193181468 <+152>: cmeq.16b v1, v0, v1 0x19318146c <+156>: and.16b v0, v0, v1 Target 0: (ar) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0000000193181460 libsystem_platform.dylib`_platform_strcmp + 144 frame #1: 0x0000000100006440 ar`main(argc=1, argv=0x000000016fdfef58) at ar.c:126:8 frame #2: 0x0000000192e2be50 dyld`start + 2544 Signed-off-by: Yifeng Li <tomli@tomli.me>
Fix build on macOS 13
[cctools] fix ar(1) crash without argument
Some tools like (or just?) meson explicitly query the version string and pattern to establish what kind of linker they are dealing with. So return a compatible string, such that those tools believe this is just an Apple linker, which is for most intents and purposes exactly what we want. This is an alternative to getting meson to recognise xtools. mesonbuild/meson#10805 See for the original problem: https://bugs.gentoo.org/868516 Signed-off-by: Fabian Groffen <grobian@gentoo.org>
|
Um... this seems like kind of a lot? Do they all really need to be combined into a single PR? |
|
hmmyeah, not sure what went wrong here, these are now fixes for Darwin in general. |
|
also it looks like this includes PR #8 as well? It'd probably be better to get that one merged separately first... |
|
hmm I have no idea how I missed this PR (somehow I got no email) only spotted because of the #7 patch. (a) I guess this is still relevant? |
|
Ok, I should probably revive this then and make it more consumable. Of course you can cherry pick commits if you see something useful. I was under the impression there was no interest in it, and I think I pushed additional fixes to the same branch or something. I'll look into cleaning this up. |
|
sadly, this is not $dayjob - it's not lack of interest, just very limited time :( Actually, I am willing to cherry-pick individual commits - if that suits you. For information: I have a much more compatible xtools branch for OSX-10.4 - 10.8 (which includes the ability to run the ld64 tests) - it is buildable starting from Apple's gcc-4.2.1. This will become xtools-0.7.0 and will be recommended for all archs in that OS range) I am hoping to get some cycles on xtools in November. |
|
Same here, and I frankly forgot about this. Certainly looking forward to using a newer xtools (0.7.0 being newer than 2.2.4?). It's the default linker on Gentoo for macOS, except arm64 where it doesn't work. |
The idea is to try to move to building whole toolchains that are matched to the OS versions they are trying to support - so that:
"One-size-fits-all" is an attractive idea - but it gets increasingly complex to maintain. e.g. - One issue is that 32b support got ripped out - so that if we try to support powerpc on "latest available" Xcode sources we are not only adding back powerpc but also the 32b stuff. Not impossible (it's all "just code") but time taken could be significant. edit: A secondary motivation is to pick the most modern toolchain components that we can realistically bootstrap on the target using only the available Xcode version (so, for example, on 10.5 we need to start from gcc-4.2.1 + ld64-85.2.1 + dwarfutils dsymutil and use that to bootstrap a capable C++11/4 toolchain). Moving much beyond ld64-236 really means using a C++11 compiler (hence the recommendation to use 0-7-0 for the platform versions that do not have a usable C++11 compiler installed).
Likewise, we have to make changes to the latest published - (Xcode 12.0 sources, currently) and then add that to the arm64 braches (also here) - although we are trying to upstream the arm64 support. |
There was a problem hiding this comment.
OK, so, yes, this file is old and obsolete, but would it really harm anything just to leave it?
| xtools_version, package_version, apple_version); | ||
| exit(0); | ||
| } else if(strcmp(argv[1], "--help") == 0){ | ||
| } else if(argc >= 2 && strcmp(argv[1], "--help") == 0){ |
There was a problem hiding this comment.
These changes were already included in #8 which has been merged; I wonder why they're still showing up as part of the diff here?
| lname = 0; | ||
| } else if (lname > sizeof(hdr->ar_name) || strchr(name, ' ')) | ||
| (void)sprintf(hb, HDR1, AR_EFMT1, (lname + 3) & ~3, | ||
| (void)sprintf(hb, HDR1, AR_EFMT1, |
There was a problem hiding this comment.
I wonder if it'd be worthwhile to change sprintf() to snprintf() while you're here?
| } | ||
| while (skip_past_comma (&str) != FAIL | ||
| || (in_range = 1, *str++ == '-')); | ||
| || ((void)(in_range = 1), *str++ == '-')); |
There was a problem hiding this comment.
if this is just to silence -Wcomma, I generally think it's better to just ignore that warning, or to apply some other method of solving it, instead of applying its suggestion to add a (void) cast. But I guess that's a matter of opinion.
| } | ||
|
|
||
| namelen = nameend - newname; | ||
| namelen = (int)(nameend - newname); |
There was a problem hiding this comment.
instead of casting to int, I think it might be better to just change the type of namelen where it's originally declared. It looks like ptrdiff_t might be the appropriate type here? Or maybe size_t, based on how it's used later...
| value = 0; | ||
| #else | ||
| if (!fixP->fx_done && 0) | ||
| // The goggles do nothing! |
There was a problem hiding this comment.
instead of commenting this out, maybe just change the preprocessor conditional that it's in?
| out_abbrev (DW_AT_ranges, DW_FORM_data4); | ||
| else | ||
| out_abbrev (DW_AT_ranges, DW_FORM_data8); | ||
| // The goggles do nothing |
There was a problem hiding this comment.
Instead of commenting this out, maybe just change the conditional?
| { | ||
| const reg_entry *r; | ||
| char *end_op; | ||
| char *end_op = NULL; |
There was a problem hiding this comment.
unnecessary whitespace added as indentation here?
| char *end_op = NULL; | |
| char *end_op = NULL; |
| /* Size of relocation record. */ | ||
| const int md_reloc_size = 8; | ||
|
|
||
| void md_create_short_jump (char *ptr, addressT from_addr, addressT to_addr, fragS *, symbolS *to_symbol); |
There was a problem hiding this comment.
So, what I'd do here would be to move the newly-added prototypes to i386.h, since they're extern, and then update the function definitions here so that they're no longer old-style.
| uint32_t left21, right14; | ||
| #endif | ||
|
|
||
| /* the pragmas that follow silence a noisy clang warning */ |
There was a problem hiding this comment.
maybe put them in an #ifdef __clang__ preprocessor conditional, then?
| * get_arch_name_if_known() returns the name of the architecture for the | ||
| * specified cputype and cpusubtype if known. If unknown it returns NULL. | ||
| */ | ||
| __private_extern__ const char *get_arch_name_if_known( |
There was a problem hiding this comment.
Isn't __private_extern__ deprecated? See the following GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106672
| arm_thread_state64_t *cpu, | ||
| enum byte_sex target_byte_sex); | ||
|
|
||
| __private_extern__ void swap_arm_exception_state64_t( |
There was a problem hiding this comment.
Again with the __private_extern__s in this file, too.
| get_stack_size_from_flag( | ||
| const struct arch_flag *flag) | ||
| { | ||
| #ifdef __MWERKS__ |
There was a problem hiding this comment.
New code with an #ifdef __MWERKS__? Does anyone still even have a Metrowerks compiler to test with? Also, this code looks like it's just attempting to avoid a warning about an unused parameter, and I thought that Metrowerks also supported GCC's #pragma unused for that purpose?
| PG = -pg | ||
|
|
||
| ifeq "$(RC_MACOS)" "YES" | ||
| DYNAMICLIB_FLAGS = -Wl,-iosmac_version_min,12.0 |
There was a problem hiding this comment.
The variable being checked says MACOS, but the flag being used is an iOS one? Is that correct?
| * returned. | ||
| */ | ||
| /* | ||
| * MDT 20190119 rdar://12400897 |
There was a problem hiding this comment.
Has this one been posted to OpenRadar? I looked for it there, but couldn't find it...
| uint64_t offset; | ||
| uint32_t align; | ||
|
|
||
| /* silence clang warning */ |
There was a problem hiding this comment.
which flag does it come from, specifically?
(likewise, wherever else a comment mentions silencing a warning, please update those comments to say which one, as well)
|
I need to sort this out, but my PowerMac is dying (it seems) and attempt to get Intel-based fallback hasn't been much of a success either. I think most of these diffs are not the once I introduced, because for some reason I messed up this PR. So I'm going to close it because it's obviously gibberish at this point, and I can't tell what should be good or bad or necessary. All I know is it works fine on x86_64 on Ventura still with GCC. |
4 participants
system info:
% gcc -dumpmachine
powerpc-apple-darwin9
% gcc -dumpversion
10.1.0
% ld -v
@(#)PROGRAM:ld PROJECT:ld64-97.17 (Gentoo binutils-apple-3.2.6)
Library search paths:
/Volumes/Scratch/Gentoo/Leopard/usr/lib
/Volumes/Scratch/Gentoo/Leopard/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
ld: warning: -arch not specified
ld: no object files specified for inferred architecture ppc