On Wed, Jan 03, 2018 at 07:47:55PM -0600, Kyle Evans wrote: > On Wed, Jan 3, 2018 at 6:54 PM, David Gibson > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jan 03, 2018 at 08:03:27AM -0600, Kyle Evans wrote: > >> On Tue, Jan 2, 2018 at 9:55 PM, David Gibson > >> <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> > [... snip ...] > >> > Great. MacOS support is interesting in particular, because unlike > >> > FreeBSD, I can set up a Travis build to test it there, which means I'm > >> > much more likely to catch regressions. In fact, looks like I have a > >> > stale branch here that added an OSX build to the travis.yml - I think > >> > some of the errors you've found and didn't have time to debug them > >> > (debugging when your only host is indirect through Travis is pretty > >> > painful). > >> > >> It'd be interesting to see those results as of recent. Their userland > >> should be similar enough in the ways you care about for the results to > >> likely be relevant to us, I would think. > > > > I rebased and tried it again: > > https://travis-ci.org/dgibson/dtc/jobs/324587391 > > > > Looks like we're getting problems with the interesting way I (ab)use > > the assembler to produce a test blob. I've hit a number of problems > > with that over time, so I'd really like to replace it with something > > else. Unfortunately, I haven't yet thought of a replacement that > > wouldn't be a pain in the arse. > > That's interesting- I wonder what version of LLVM this maps to? Or are > they so far gone that it doesn't matter? We've got an effort over here > going to replace our system linker with LLD; the version of LLD that > we're optionally using on -HEAD right now has no problem with this: > > $ ld.lld --version > LLD 5.0.1 (FreeBSD 320880) (compatible with GNU linkers) I think the problem is at the asm level, rather than the linker level. Specifically I think it's failing to realize that expressions of the form (sym2 - sym1) where sym2 and sym1 are both local labels are actually assemble time constant and don't need relocation, even if the symbols themselves do. If they actually did need relocation, I don't think they're in a form I'd expect any linker to be able to cope with (or even the ELF format itself). I suppose it's possible there's something in the OSX ABI which means these things really can't be assemble time evaluated, in which case we'd be pretty stuck. According to the Travis logs it's using: $ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.1.0 (clang-802.0.42) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin I'm assuming it will be using the same LLVM version for assembling as compiling. Given how out of date the Linux images often are on Travis, it wouldn't suprise me of the OSX ones are as well. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
