[Vm-dev] The Mac VM (pharo)
Das.Linux at gmx.de
Thu Sep 26 08:35:05 UTC 2013
Am 26.09.2013 um 10:06 schrieb Eliot Miranda <eliot.miranda at gmail.com>:
> Hi Tobias,
>>> No; very different. I'm not an expert but I think essentially clang is
>>> Apple's C compiler that uses the LLVM backend, and gcc is good old gcc.
>> Not on a default Mac Xcode installation.
>> See my OSX 10.8 + Xcode 4.x installation:
>> $ ls -al $(which gcc)
>> lrwxr-xr-x 1 root wheel 12 24 Apr 16:42 /usr/bin/gcc -> llvm-gcc-4.2
>> But with Xcode 5, no gcc (be it a pure gcc-4.2 or a llvm backed gcc)
>> ships. gcc is linked to clang.
>> It is a problem of default naming. From Xcode 5 on, if you don't change
>> a thing, "gcc" will get you "clang".
> I think you miss my point, which is that the clang compiler is very
> different (it uses LLVM for its code generator) than gcc.
I got that point, but I was under the impression, Göran wanted to
make a different one.
> That apple calls
> clang gcc is neither here-nor-there. If you get a real gcc it will compile
> a functional VM. If you get a clang-based compiler it won't. Do you agree?
Yes, I did not want to argue that point :).
But what is with the two-headed hydra, llvm-gcc (gcc frontend with llvm code-gen)?
Since Xcode 4, apple by default does _not_ ship a "normal" gcc but only a
llvm-based one, and with Xcode 5, even that is gone.
My point was not about code-gen but compiler-availability ;)
However, yours seem more important ATM.
>>> Right now Cog doesn't run if compiled with clang. Only gcc will do. No
>>> time to debug this right now, and annoyingly clang compiles all static
>>> functions with a non-standard calling convention which means one can;t
>>> these functions in gdb, hence lots of debugging functions aren't
>>> without either a) turning off the optimization or b) changing the VM
>>> so they're not static.
>> you might want to try lldb, that ships with Xcode and is based on the
>> llvm/clang tool chain. I am not implying it is better than gcc but
>> maybe it can help in your situation?
> Thanks, that sounds promising!
Keep in mind, that not only on the technical level
lldb is to gdb what clang is to gcc, but also on the
“philosophical”, as in
“emulate the interface of gcc/gdb but not quite…”
Be prepared for surprises, good ones and bad ones.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130926/466aa9f8/signature.pgp
More information about the Vm-dev