| 1 |
Hi Fabian, |
| 2 |
|
| 3 |
On Tue, Dec 11, 2018 at 02:32:37PM +0100, Fabian Groffen wrote: |
| 4 |
|
| 5 |
> > That was the reason I added PPC support back into newer versions of ld64 |
| 6 |
> > in the hope that the cause of the mislinkage had been fixed |
| 7 |
> > incidentally somehow. But that was not the case. (The newer ld64 linked |
| 8 |
> > no worse either, though. :) |
| 9 |
> Indeed, 6.3 (version that can be compiled without issues lacking clang) |
| 10 |
> works very well, and is able to compile @system. |
| 11 |
|
| 12 |
One potentially confusing difference comes to mind: If you look with |
| 13 |
system otool on OS X 10.4/10.5 you will find unsupported load commands |
| 14 |
added by the newer ld64. But since dyld just ignores them and ld64 |
| 15 |
doesn't leave out any of the older load commands in favour of newer |
| 16 |
ones, that shouldn't be any problem. |
| 17 |
|
| 18 |
Apropos: Apple has released Xcode source all the way up to 10.0. Is |
| 19 |
anyone working on updating binutils-apple already? Otherwise I'd give it |
| 20 |
a go over the upcoming holidays. |
| 21 |
|
| 22 |
Do you have any need to have PPC support added back into current |
| 23 |
ld64/cctools? |
| 24 |
|
| 25 |
> > A workaround I found was to link the mislinked library (one of the |
| 26 |
> > zillon libLLVM*.dylibs) incrementally. I'm not quite sure any more how I |
| 27 |
> > did that exactly but it produced a working clang. |
| 28 |
> Hmm, I wonder if it being a 32-bits linker is part of the problem then. |
| 29 |
|
| 30 |
I was testing on an iBook G4 with 1GB of RAM. If address space were a |
| 31 |
problem, I'd have expected it to bail with some kind of error (ENOMEM, |
| 32 |
segfault, ...) or the machine swapping like crazy. Neither happened: It |
| 33 |
linked the binary fine but the resulting binary threw bus-errors |
| 34 |
reproducibly when run. |
| 35 |
|
| 36 |
Silent mislinking smells like some kind of corruption to me, e.g. hash |
| 37 |
table collisions or stuff like that due to the sheer amount of symbols, |
| 38 |
relocations and other stuff to track and resolve during linking. |
| 39 |
|
| 40 |
I had tried to find the difference between an incrementally linked, |
| 41 |
working clang and the bus-erroring one but was not even able to find an |
| 42 |
obvious difference causing this due to the sheer size of the binary and |
| 43 |
the libs it loads. I might even have trakced it to some assembly |
| 44 |
instruction doing the bus-error-causing memory access but then lacked |
| 45 |
the debugging-fu to trace this back to the object file and type of |
| 46 |
relocation this resulted from to even get an inkling of what might be |
| 47 |
going on inside ld64 to cause this. |
| 48 |
|
| 49 |
If you come across a similar but smaller reproducer for this problem, |
| 50 |
feel free to throw it at me for debugging. |
| 51 |
|
| 52 |
> For now I deferred clang/llvm, compiler-rt lacks powerpc support last I |
| 53 |
> checked. |
| 54 |
|
| 55 |
IIRC, last I checked (3.4.2/3.5.1/3.7) compiler-rt had powerpc support |
| 56 |
and it did compile with some minor tweaks for old OS X versions |
| 57 |
(10.4/10.5). All the ASAN stuff didn't compile though and had to be |
| 58 |
disabled. |
| 59 |
-- |
| 60 |
Thanks, |
| 61 |
Michael |
Archives