Re: GNUstep base almost builds with clang
On 30 Mar 2009, at 16:37, David Chisnall wrote: The remaining issue is that clang (and llvm-gcc, for that matter) does not support the __builtin_apply() family of intrinsics. These are quite unreliable on GCC, and it seems that they are not used when FFCall or FFI is supported, but are still compiled in. mframe.m (which is really horrible) seems to be compiled unconditionally, even though it does not seem to be used when ffcall or libffi is provided. NSInvocation.m provides default implementations in terms of __builtin_apply() and friends that are not used when libffi or ffcall is provided. Is it possible to move these into a separate concrete subclass of NSInvocation along the lines of GSFFIInvocation/ GSFFCallInvocation and only compile them when no better mechanism is provided? I should think that's not only possible, but a very good idea. I *think* (iirc) a little of the code in mframe is used for some NSMethodSgnature features. It may be that we always need that part compiled in, but it should be possible to separate out what we need, and only build the rest of the code if we don't have libffi or ffcall. objc-gnu2next.m uses them in a function that is deprecated on the legacy Apple runtime and not supported by the modern Apple runtime. Does anyone actually use next_objc_msg_sendv()? I don't but it's always dangerous to assume that nobody else will. On the other hand, that's old enough that we might insist on people changing. The next major release will need to break ABI compatibility for 64bit code in order to be compatible with Apple's recent changes, so now is probably a good time to introduce other cleanups that break the ABI in little-used or unused ways. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote: On 30 Mar 2009, at 16:37, David Chisnall wrote: NSInvocation.m provides default implementations in terms of __builtin_apply() and friends that are not used when libffi or ffcall is provided. Is it possible to move these into a separate concrete subclass of NSInvocation along the lines of GSFFIInvocation/GSFFCallInvocation and only compile them when no better mechanism is provided? I should think that's not only possible, but a very good idea. Great news. I *think* (iirc) a little of the code in mframe is used for some NSMethodSgnature features. It may be that we always need that part compiled in, but it should be possible to separate out what we need, and only build the rest of the code if we don't have libffi or ffcall. Using the power of grep, I see: NSMethodSignature uses some mframe stuff for parsing type encodings. This doesn't really make sense being in mframe.m, since it's nothing to do with creating call frames. NSConnection uses them in -forwardForProxy:selector:argFrame:, which I believe is deprecated since all of the argframe stuff was deprecated years ago and never worked correctly, and in a few places with #ifdefs so they're not actually compiled. NSInvocation.m uses them in the fall-back code for when ffcall and libffi are not present. NSObjCRuntime.m uses mframe_next_arg in NSGetSizeAndAlignment(). The stuff for decoding type strings should probably be pulled into a separate file. objc-gnu2next.m uses them in a function that is deprecated on the legacy Apple runtime and not supported by the modern Apple runtime. Does anyone actually use next_objc_msg_sendv()? I don't but it's always dangerous to assume that nobody else will. On the other hand, that's old enough that we might insist on people changing. The next major release will need to break ABI compatibility for 64bit code in order to be compatible with Apple's recent changes, so now is probably a good time to introduce other cleanups that break the ABI in little-used or unused ways. This function seems to be part of an attempt to reproduce the old NeXT runtime API. More recently, I've been working on implementing the ObjC 2.0 runtime API (supported by Apple for both their new and old runtimes) on top of the GNU one. You can see the current version here: http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/ At some point, I'd like to push this up to GNUstep[1] and have the Apple runtime APIs properly supported. Now that Apple has deprecated posing and defined a stable public API for the runtime, I would imagine a lot of programs are going to start using it. David [1] If possible, I'd like to keep the MIT license for these files so they can be easily used outside of GNUstep as well, since they are low- level and have potential applications for Objective-C code that does not use GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Hello David, Am Dienstag, den 31.03.2009, 17:49 +0100 schrieb David Chisnall: > On 31 Mar 2009, at 17:13, Richard Frith-Macdonald wrote: > > > On 30 Mar 2009, at 16:37, David Chisnall wrote: > > > > I *think* (iirc) a little of the code in mframe is used for some > > NSMethodSgnature features. It may be that we always need that part > > compiled in, but it should be possible to separate out what we need, > > and only build the rest of the code if we don't have libffi or ffcall. > > Using the power of grep, I see: > > NSMethodSignature uses some mframe stuff for parsing type encodings. > This doesn't really make sense being in mframe.m, since it's nothing > to do with creating call frames. > > NSConnection uses them in -forwardForProxy:selector:argFrame:, which I > believe is deprecated since all of the argframe stuff was deprecated > years ago and never worked correctly, and in a few places with #ifdefs > so they're not actually compiled. I'm mostly concerned about keeping support for deprecated API which was 1) part of either the OpenStep specification. 2) part of OPENSTEP 4.2 (widely distributed cross platform implementation of OpenStep) 3) part of WebObject 4.5 (last cross platform implementation of OpenStep) If we can implement the argframe approach (ie. -forward::) via libffi then we could also resolve some long standing libobjc issues. Yet I'm still unsure if it can be done at all. I'm also a bit concerned about statements like "I believe ...[some code]... never worked correctly" as we simply do not know who is using it and whether it works for production code. Mostly one finds out that things stopped working when it's too late... (For example currently it seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't maintaining it anymore, and I hardly know anything about c++ to be of much use here... I'm am trying to takle some of the objc/libobjc bits.) What I'd /really/ like to see is that we would start setting up our "Test Farm" to also run the test suite and possibly get something like: http://gcc.gnu.org/wiki/CompileFarm running for "Supported Platforms". But even if we had access to such a farm, I don't really have the time to volunteer to maintain it. > NSInvocation.m uses them in the fall-back code for when ffcall and > libffi are not present. I think we should deprecate the fallback and log a message asking users who stumble over it to post their architecture/platform information. The goal would be to find someone who could implement libffi support for that architecture/platform. > NSObjCRuntime.m uses mframe_next_arg in NSGetSizeAndAlignment(). > > The stuff for decoding type strings should probably be pulled into a > separate file. Indeed... I think I once started a patch to extract mframe_next_arg into GSObjCRuntime.m under a different name. I'm not sure anymore what happened to it. But I agree that this function shouldn't need any of the code in mframe.m itself. > >> objc-gnu2next.m uses them in a function that is deprecated on the > >> legacy Apple runtime and not supported by the modern Apple > >> runtime. Does anyone actually use next_objc_msg_sendv()? > > > > I don't but it's always dangerous to assume that nobody else will. > > On the other hand, that's old enough that we might insist on people > > changing. The next major release will need to break ABI > > compatibility for 64bit code in order to be compatible with Apple's > > recent changes, so now is probably a good time to introduce other > > cleanups that break the ABI in little-used or unused ways. > > This function seems to be part of an attempt to reproduce the old NeXT > runtime API. More recently, I've been working on implementing the > ObjC 2.0 runtime API (supported by Apple for both their new and old > runtimes) on top of the GNU one. You can see the current version here: > > http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/ > > At some point, I'd like to push this up to GNUstep[1] and have the > Apple runtime APIs properly supported. Now that Apple has deprecated > posing and defined a stable public API for the runtime, I would > imagine a lot of programs are going to start using it. > I think the proper place to put this is FSF libobjc. I'd support a request to dual-license the respective files. (Not that I have any real clout but if we as a project request it, maybe are chances are not that bad.) > [1] If possible, I'd like to keep the MIT license for these files so > they can be easily used outside of GNUstep as well, since they are low- > level and have potential applications for Objective-C code that does > not use GNUstep. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 31 Mar 2009, at 20:00, David Ayers wrote: I'm mostly concerned about keeping support for deprecated API which was 1) part of either the OpenStep specification. 2) part of OPENSTEP 4.2 (widely distributed cross platform implementation of OpenStep) 3) part of WebObject 4.5 (last cross platform implementation of OpenStep) I'd agree with this. -forwardForProxy:selector:argFrame: is not part of OpenStep. I don't know if it was part of OPENSTEP 4.2 or WO - my impression was that it was a private GNUstep method that had since been superseded by the ffi stuff. If we can implement the argframe approach (ie. -forward::) via libffi then we could also resolve some long standing libobjc issues. Yet I'm still unsure if it can be done at all. I'm also a bit concerned about statements like "I believe ...[some code]... never worked correctly" as we simply do not know who is using it and whether it works for production code. Mostly one finds out that things stopped working when it's too late... Reading the GCC and GNUstep lists, __builtin_apply() and friends are in the 'it may work, but if it stops working randomly then don't be surprised' category. Every time someone asks a question about them on the GCC lists, the reply seems to be 'don't use them unless you absolutely have to'. I am only proposing that we deprecate bits of GNUstep that are not in code paths that are used in the standard configurations and have not been for several years, including some parts that contain comments indicating that they probably don't work. (For example currently it seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't maintaining it anymore, and I hardly know anything about c++ to be of much use here... I'm am trying to takle some of the objc/libobjc bits.) This is one of the reasons I want to get clang supporting GNUstep. C+ + support in clang is still very immature, but it is improving at a rapid pace, and Apple has several people working on it full time. Because it uses a unified parser, the Objective-C++ front end supports everything that C++ one does. All we need to do to be able to make use of this is ensure that the CGObjCGNU class is implemented correctly. What I'd /really/ like to see is that we would start setting up our "Test Farm" to also run the test suite and possibly get something like: http://gcc.gnu.org/wiki/CompileFarm running for "Supported Platforms". But even if we had access to such a farm, I don't really have the time to volunteer to maintain it. NSInvocation.m uses them in the fall-back code for when ffcall and libffi are not present. I think we should deprecate the fallback and log a message asking users who stumble over it to post their architecture/platform information. The goal would be to find someone who could implement libffi support for that architecture/platform. I'd suggest modifying the configure script. The ffcall implementation doesn't work safely with EtoileThread, since it does not provide a mechanism for preventing the invocation from trampling over a random stack address if it lasts longer than the call frame. When I reported this, there was talk of deprecating ffcall, since there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't. I would suggest that for the next release we require libffi and see if anyone complains. NSObjCRuntime.m uses mframe_next_arg in NSGetSizeAndAlignment(). The stuff for decoding type strings should probably be pulled into a separate file. Indeed... I think I once started a patch to extract mframe_next_arg into GSObjCRuntime.m under a different name. I'm not sure anymore what happened to it. But I agree that this function shouldn't need any of the code in mframe.m itself. objc-gnu2next.m uses them in a function that is deprecated on the legacy Apple runtime and not supported by the modern Apple runtime. Does anyone actually use next_objc_msg_sendv()? I don't but it's always dangerous to assume that nobody else will. On the other hand, that's old enough that we might insist on people changing. The next major release will need to break ABI compatibility for 64bit code in order to be compatible with Apple's recent changes, so now is probably a good time to introduce other cleanups that break the ABI in little-used or unused ways. This function seems to be part of an attempt to reproduce the old NeXT runtime API. More recently, I've been working on implementing the ObjC 2.0 runtime API (supported by Apple for both their new and old runtimes) on top of the GNU one. You can see the current version here: http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/ At some point, I'd like to push this up to GNUstep[1] and have the Apple runtime APIs properly supported. Now that Apple has deprecated posing and defined a stable public API for the runtime, I would imagine a lot of programs ar
Re: GNUstep base almost builds with clang
Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall: > On 31 Mar 2009, at 20:00, David Ayers wrote: > > > I'm mostly concerned about keeping support for deprecated API which > > was > > 1) part of either the OpenStep specification. > > 2) part of OPENSTEP 4.2 (widely distributed cross platform > > implementation of OpenStep) > > 3) part of WebObject 4.5 (last cross platform implementation of > > OpenStep) > > I'd agree with this. -forwardForProxy:selector:argFrame: is not part > of OpenStep. I don't know if it was part of OPENSTEP 4.2 or WO - my > impression was that it was a private GNUstep method that had since > been superseded by the ffi stuff. Indeed... and I don't mind removing forwardForProxy:... as long as we can continue to support -forward:: for those archs that still still work with it...unless we officially want to deprecate support those archs. > > If we can implement the argframe approach (ie. -forward::) via libffi > > then we could also resolve some long standing libobjc issues. Yet I'm > > still unsure if it can be done at all. > > > > I'm also a bit concerned about statements like "I believe ...[some > > code]... never worked correctly" as we simply do not know who is using > > it and whether it works for production code. Mostly one finds out > > that > > things stopped working when it's too late... > > Reading the GCC and GNUstep lists, __builtin_apply() and friends are > in the 'it may work, but if it stops working randomly then don't be > surprised' category. Every time someone asks a question about them on > the GCC lists, the reply seems to be 'don't use them unless you > absolutely have to'. > > I am only proposing that we deprecate bits of GNUstep that are not in > code paths that are used in the standard configurations and have not > been for several years, including some parts that contain comments > indicating that they probably don't work. OK, but the consequence is deprecating platforms. And that should be stated and communicated as such. I'm not too fond of doing that without very good reasons. > > (For example currently it > > seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't > > maintaining it anymore, and I hardly know anything about c++ to be of > > much use here... I'm am trying to takle some of the objc/libobjc > > bits.) > > This is one of the reasons I want to get clang supporting GNUstep. C+ > + support in clang is still very immature, but it is improving at a > rapid pace, and Apple has several people working on it full time. > Because it uses a unified parser, the Objective-C++ front end supports > everything that C++ one does. All we need to do to be able to make use > of this is ensure that the CGObjCGNU class is implemented correctly. Well I'm not too fond of yet another compiler/runtime to support... but if it is what apple will be using and it will also replace the current apple runtime, I'm glad someone is working on it. But I think will need insure that our current main compiler / runtime stays in (or is restored to) a decent condition. > I'd suggest modifying the configure script. The ffcall implementation > doesn't work safely with EtoileThread, since it does not provide a > mechanism for preventing the invocation from trampling over a random > stack address if it lasts longer than the call frame. When I reported > this, there was talk of deprecating ffcall, since there don't appear > to be any platforms where GNUstep and ffcall work but libffi doesn't. > I would suggest that for the next release we require libffi and see if > anyone complains. Where do you get the information that "there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't"? IIRC peoples mileage varies. But indeed we need to start documenting which works with which. > >> ... More recently, I've been working on implementing the > >> ObjC 2.0 runtime API (supported by Apple for both their new and old > >> runtimes) on top of the GNU one. You can see the current version > >> here: > >> > >> http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Languages/RuntimeAbstraction/ > >> > >> At some point, I'd like to push this up to GNUstep[1] and have the > >> Apple runtime APIs properly supported. Now that Apple has deprecated > >> posing and defined a stable public API for the runtime, I would > >> imagine a lot of programs are going to start using it. > >> > > > > I think the proper place to put this is FSF libobjc. I'd support a > > request to dual-license the respective files. (Not that I have any > > real > > clout but if we as a project request it, maybe are chances are not > > that > > bad.) > > Has anyone heard anything from the FSF about relicensing the GNU > runtime? It is currently GPL with an exemption that only applies if > code is compiled with GCC. I was told about a year ago that it would > be moved to the same exemption as libc (whic
Re: GNUstep base almost builds with clang
On 1 Apr 2009, at 00:28, David Ayers wrote: Am Dienstag, den 31.03.2009, 22:13 +0100 schrieb David Chisnall: On 31 Mar 2009, at 20:00, David Ayers wrote: If we can implement the argframe approach (ie. -forward::) via libffi then we could also resolve some long standing libobjc issues. Yet I'm still unsure if it can be done at all. I'm also a bit concerned about statements like "I believe ...[some code]... never worked correctly" as we simply do not know who is using it and whether it works for production code. Mostly one finds out that things stopped working when it's too late... Reading the GCC and GNUstep lists, __builtin_apply() and friends are in the 'it may work, but if it stops working randomly then don't be surprised' category. Every time someone asks a question about them on the GCC lists, the reply seems to be 'don't use them unless you absolutely have to'. I am only proposing that we deprecate bits of GNUstep that are not in code paths that are used in the standard configurations and have not been for several years, including some parts that contain comments indicating that they probably don't work. OK, but the consequence is deprecating platforms. And that should be stated and communicated as such. I'm not too fond of doing that without very good reasons. Are we? What platforms currently have no support for either ffcall or libffi, but do have support for __builtin_apply()? (Note the last condition; the further you get from Linux/x86, the less likely __builtin_apply() is to actually work) (For example currently it seems that gcc 4.5 may be breaking obj-c++ in gcc because Apple isn't maintaining it anymore, and I hardly know anything about c++ to be of much use here... I'm am trying to takle some of the objc/libobjc bits.) This is one of the reasons I want to get clang supporting GNUstep. C+ + support in clang is still very immature, but it is improving at a rapid pace, and Apple has several people working on it full time. Because it uses a unified parser, the Objective-C++ front end supports everything that C++ one does. All we need to do to be able to make use of this is ensure that the CGObjCGNU class is implemented correctly. Well I'm not too fond of yet another compiler/runtime to support... but if it is what apple will be using and it will also replace the current apple runtime, I'm glad someone is working on it. But I think will need insure that our current main compiler / runtime stays in (or is restored to) a decent condition. Neither am I, but no one on the GCC side seems to be working on Objective-C. I tried to persuade the FreeBSD port maintainer to enable ObjC++ recently in the default build, and his reaction was that ObjC was basically unmaintained in GCC and ObjC++ was in an even worse state. Someone at Apple created some patches over a year ago for adding support for properties to GCC on the GNU runtime. Are they merged yet? No. Is anyone planning on merging them, or rewriting their functionality? Not as far as I can see. Do any of the GCC folks outside of Apple give a dam about Objective-C? Not that I can tell; we had a /stable/ release ship generating errors with any Objective-C program containing constant strings a while ago, and the GCC response was 'Objective-C is not a priority'. If we continue to treat GCC as our main compiler then run the risk that we are depending on a project which has no interest in maintaining the features we need. As far as I can tell, the only reason ObjC is even included in the default builds for GCC is so that the FSF can keep that page telling everyone how great the GPL is because it got GCC its ObjC front-end and ignoring the fact that the code they got was horrible, unmaintainable, and completely useless until someone wrote a libobjc implementation (which ended up being more code than the compiler front end). I'd suggest modifying the configure script. The ffcall implementation doesn't work safely with EtoileThread, since it does not provide a mechanism for preventing the invocation from trampling over a random stack address if it lasts longer than the call frame. When I reported this, there was talk of deprecating ffcall, since there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't. I would suggest that for the next release we require libffi and see if anyone complains. Where do you get the information that "there don't appear to be any platforms where GNUstep and ffcall work but libffi doesn't"? IIRC peoples mileage varies. But indeed we need to start documenting which works with which. From the mailing list when I asked this last, and from comparing the list of supported platforms for the two. Again, can you name one platform supported by ffcall and GNUstep, but not libffi? Does anyone want to jump in and say 'My platform doesn't support libffi! Please don't dro
Re: GNUstep base almost builds with clang
> From the mailing list when I asked this last, and from comparing the > list of supported platforms for the two. Again, can you name one > platform supported by ffcall and GNUstep, but not libffi? Does anyone > want to jump in and say 'My platform doesn't support libffi! Please > don't drop support!' or is this all hypothetical? My platform (FreeBSD/amd64) supports ffcall but not libffi (or this was the case last time I compiled GNUstep about a month ago) so please don't drop support :-) All the rest of the email, however, I agree with - the lack of ObjC maintenance on GCC worries me greatly. I depend on this stuff for my living, and for my business to make sales. Having somewhere else to jump to would make me give a huge sigh of relief. -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 1 Apr 2009, at 00:56, Pete French wrote: My platform (FreeBSD/amd64) supports ffcall but not libffi (or this was the case last time I compiled GNUstep about a month ago) so please don't drop support :-) The FreeBSD port for libffi is not marked as broken on amd64. I'd be very surprised if libffi worked on x86-64 Linux but not FreeBSD, since they use exactly the same calling convention on this architecture (Linux uses PCC-compatible on-stack small-structure returns while FreeBSD returns them in register, and a few other minor differences on i386, but in 64-bit mode they are the same). Would it be possible for you to check whether GNUstep works with libffi? On FreeBSD/i386, it defaults to using ffcall, but works better with libffi (i.e. doesn't randomly corrupt the stack when you pass NSInvocations between threads). You probably need to explicitly specify /usr/local/include and /usr/local/lib as ffi lib/include directories in configure. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On Tue, Mar 31, 2009 at 4:56 PM, Pete French wrote: > All the rest of the email, however, I agree with - the lack of > ObjC maintenance on GCC worries me greatly. I depend on this > stuff for my living, and for my business to make sales. Having > somewhere else to jump to would make me give a huge sigh of relief. Well if your business depends on it, you might want to hire someone someone to do the development. Apple has moved away from GCC so you can no longer depend on them. Maybe it is just me and your business model is incorrect to depend on free things when in reality there is no such thing as a free lunch. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> Well if your business depends on it, you might want to hire someone > someone to do the development. Well, that would be me. But I kind of have a lot of other stuff to do. I'll reprhrase it as "I dont want to take this on myself". > Apple has moved away from GCC so you can no longer depend on them. This I did not know. Interesting. I assumed Xcode was still using gcc. > Maybe it is just me and your business model is incorrect to depend on > free things when in reality there is no such thing as a free lunch. By that argument nobody should run a business on top of BSD or Linux. Yes, if you are going to be pedantic I dont "depend" on them - If BSD went away I would switch to Solaris, and if free Objective-C compilers went away then I shall switch to OS X. But in practice, currently the software runs on top of BSD using GCC/ObjC and it would be an imense pain if either of those things vanished tomorrow. But they are not likely to in my judgement. Indeed isn't the point of the GPL that the current version can't ever be actually taken away ? Or did I misunderstand that ? -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> Would it be possible for you to check whether GNUstep works with > libffi? On FreeBSD/i386, it defaults to using ffcall, but works > better with libffi (i.e. doesn't randomly corrupt the stack when you > pass NSInvocations between threads). You probably need to explicitly > specify /usr/local/include and /usr/local/lib as ffi lib/include > directories in configure. Sure I can give that a try tomorrow. Last time I looked at it I couldnt make it work with libffi, but things change. -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On Tue, Mar 31, 2009 at 5:51 PM, Pete French wrote: >> Well if your business depends on it, you might want to hire someone >> someone to do the development. > > Well, that would be me. But I kind of have a lot of other stuff to > do. I'll reprhrase it as "I dont want to take this on myself". > >> Apple has moved away from GCC so you can no longer depend on them. > > This I did not know. Interesting. I assumed Xcode was still using > gcc. I should have said moving away but really they are so close to have moved away, it can be considered moved. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> I should have said moving away but really they are so close to have > moved away, it can be considered moved. So what have they moved to out of interest, or can't you tell us ? Is this just for Obj-C or the whole operating system ? -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On Tue, Mar 31, 2009 at 6:00 PM, Pete French wrote: >> I should have said moving away but really they are so close to have >> moved away, it can be considered moved. > > So what have they moved to out of interest, or can't you tell us ? > Is this just for Obj-C or the whole operating system ? > Both, they are moving over to clang (and LLVM) witness the subject line :). -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> Both, they are moving over to clang (and LLVM) witness the subject line :). good stuff ;-) I should go re-visit llvm and clang really, I never took a proper look at it - I didn't realise it couod compile to native code, which is preseumably true if they are compiking a full OS with it [ thats probably reduyced the chnaces of me doing an real work the rest of the day to zero ! ] -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 1 Apr 2009, at 01:51, Pete French wrote: Apple has moved away from GCC so you can no longer depend on them. This I did not know. Interesting. I assumed Xcode was still using gcc. XCode currently ships with gcc and llvm-gcc. Only llvm-gcc is supported for iPhone developement (if you take a look at the LLVM commit logs, you'll notice a massive amount of ARM-backend code was committed the day the first iPhone developer kits were released). llvm-gcc is a hybrid compiler, which uses GCC to parse, then translates GIMPLE (the GCC intermediate representation) into LLVM IR and then uses LLVM for optimisation and code generation. Because it includes parts of GCC, it is GPL'd. Unfortunately for us, llvm-gcc uses Apple's branch of GCC, which is GPLv2, and (more importantly) only supports the Apple runtime. You can use it with to compile C and C++ code on non-Apple platforms, but you can't use it with Objective-C, so GNUstep can't use it. Clang is a new front-end for LLVM, written completely from scratch, which is more-or-less feature complete for C99 and Objective-C 2 (parsing anyway - code generation is only finished for the Apple runtimes), and now working towards C++ support. My understanding is that Apple intends to drop llvm-gcc once clang is a drop-in replacement (it almost is now for C and Objective-C on the Apple runtimes, but it's still probably about a year away from being ready for C++ / ObjC++). There are a few other reasons why clang might interest the GNUstep community: - It contains a static analyser, which can find a lot of different types of Objective-C bug. - It is built from several libraries, which means that you can easily reuse the parser in other programs, for example to implement code completion and syntax highlighting, or to write a version of autogsdoc that is aware of macros. - One of the demos is a rewriter, which translates ObjC code into pure C code (for the Apple runtime). Modifying this to use the GNU runtime calls would give a mechanism for compiling GNUstep on any platform with a working C compiler. Alternatively, LLVM has a C back end which can generate (completely unreadable, but semantically valid) C code from the IR. If you want an overview of LLVM, you can read this article: http://www.informit.com/articles/article.aspx?p=1215438 David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> Would it be possible for you to check whether GNUstep works with > libffi? On FreeBSD/i386, it defaults to using ffcall, but works > better with libffi (i.e. doesn't randomly corrupt the stack when you > pass NSInvocations between threads). You probably need to explicitly > specify /usr/local/include and /usr/local/lib as ffi lib/include > directories in configure. Using the latest SVN this now works out of the box with just 'configure' and the libffi port installed. So no need for ffcall on this platform anymore. cheers, -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> Clang is a new front-end for LLVM, written completely from scratch,
> which is more-or-less feature complete for C99 and Objective-C 2
> (parsing anyway - code generation is only finished for the Apple
> runtimes), and now working towards C++ support.
Is this what you were using to try and compile GNustep base ? I
have just soent a while playing around with the llvm port on
FreeBSD (which seems to be lacking the compiler driver). Had some
success with plain old C, but not a lot with ObjC, eeven when I am not
doing anything objecty. e.g:
#include
#include
#include
@interface foo : Object
@end
@implementation foo : Object
@end
int
main(int argc, char *argv[])
{
puts("Hello world");
return 0;
}
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 1 Apr 2009, at 15:10, Pete French wrote: Clang is a new front-end for LLVM, written completely from scratch, which is more-or-less feature complete for C99 and Objective-C 2 (parsing anyway - code generation is only finished for the Apple runtimes), and now working towards C++ support. Is this what you were using to try and compile GNustep base ? I have just soent a while playing around with the llvm port on FreeBSD (which seems to be lacking the compiler driver). Had some success with plain old C, but not a lot with ObjC, eeven when I am not doing anything objecty. e.g: Not sure what you are using to compile here. There is not FreeBSD port for clang, and trunk clang requires trunk LLVM (i.e. not the port). Can you tell me what commands you are trying to use to compile? David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> Not sure what you are using to compile here. There is not FreeBSD
> port for clang, and trunk clang requires trunk LLVM (i.e. not the
> port). Can you tell me what commands you are trying to use to compile?
I installed llvm-dev from ports. Which gives me a 'clang' command
that I can use like this:
clang test.m -emit-llvm -o - | llvm-as | opt -std-compile-opts | llc > test.s
cc test.s -lobjc
./a.out
That works fine as long as there are no actual Objective C
constructs inside test.m . Its a basic "hello world" at the
moment:
#include
#include
int
main(int argc, char *argv[])
{
puts("Hello world");
return 0;
}
That works fine. But if I add the line "id x = [Object new];"
at the start of main() then I get this at runtime:
Module (null) version 8 doesn't match runtime 8
Abort trap: 6 (core dumped)
That's due to me having the wrong libobjc, yes ? I was wondering what
runtime you use which works... now I can compile and run code I
am interested in experimenting with this a bit
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Patch to fix this problem is here if you want to apply it to your
local tree:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-April/004759.html
As far as I know, you are the first person to test clang Objective-C
support on a 64-bit platform. Please keep sending me reports of
things that don't work.
David
On 1 Apr 2009, at 16:35, Pete French wrote:
Not sure what you are using to compile here. There is not FreeBSD
port for clang, and trunk clang requires trunk LLVM (i.e. not the
port). Can you tell me what commands you are trying to use to
compile?
I installed llvm-dev from ports. Which gives me a 'clang' command
that I can use like this:
clang test.m -emit-llvm -o - | llvm-as | opt -std-compile-opts | llc
> test.s
cc test.s -lobjc
./a.out
That works fine as long as there are no actual Objective C
constructs inside test.m . Its a basic "hello world" at the
moment:
#include
#include
int
main(int argc, char *argv[])
{
puts("Hello world");
return 0;
}
That works fine. But if I add the line "id x = [Object new];"
at the start of main() then I get this at runtime:
Module (null) version 8 doesn't match runtime 8
Abort trap: 6 (core dumped)
That's due to me having the wrong libobjc, yes ? I was wondering what
runtime you use which works... now I can compile and run code I
am interested in experimenting with this a bit
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> Patch to fix this problem is here if you want to apply it to your > local tree: Just working out how to get a local tree ;-) Aside from GNUstep I usually just build from ports. > As far as I know, you are the first person to test clang Objective-C > support on a 64-bit platform. Please keep sending me reports of > things that don't work. Will do - and I think this has strayed a very long way from GNUstep now, so wont do so here. I have a lot of stuff I want to compile up. WWe have several tens of thousands of lines of straight objeective C built on top of libc directly, so we can eaily use llvm to run it. cheers, -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am 01.04.2009 um 14:11 schrieb David Chisnall: If you want an overview of LLVM, you can read this article: http://www.informit.com/articles/article.aspx?p=1215438 I added your interesting article to DZone http://www.dzone.com/links/ how_the_llvm_compiler_infrastructure_works.html feel free to vote it up David regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am Mittwoch, den 01.04.2009, 15:07 +0100 schrieb Pete French: > > Would it be possible for you to check whether GNUstep works with > > libffi? On FreeBSD/i386, it defaults to using ffcall, but works > > better with libffi (i.e. doesn't randomly corrupt the stack when you > > pass NSInvocations between threads). You probably need to explicitly > > specify /usr/local/include and /usr/local/lib as ffi lib/include > > directories in configure. > > Using the latest SVN this now works out of the box with just > 'configure' and the libffi port installed. So no need for ffcall > on this platform anymore. This sounds great! Could also check whether the NSProxy Tests pass? i.e. checkout http://svn.gna.org/svn/gnustep/tests/testsuite/trunk and run: ./runtest.sh base/NSProxy/test01.m Thanks! Cheers, David PS: the log file is called tests.log ... please post it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
> ./runtest.sh base/NSProxy/test01.m not so good sadly... This is gnustep-make 2.0.8. Type 'gmake print-gnustep-make-help' for help. PASS: Proxy signed char PASS: Proxy unsigned char PASS: Proxy signed short PASS: Proxy unsigned short PASS: Proxy singed int PASS: Proxy unsigned int PASS: Proxy signed long PASS: Proxy unsigned long PASS: Proxy signed long long PASS: Proxy unsigned long long PASS: Proxy float PASS: Proxy float PASS: Proxy id PASS: Proxy enum PASS: Proxy NSRange PASS: Proxy NSPoint ./obj/test01: Uncaught exception NSInvalidArgumentException, reason: GSFFIInvocation: Class 'AUATUSH'(class) does not respond to forwardInvocation: for '(null)' gmake: *** [test] Abort trap: 6 (core dumped) FAIL: base/NSProxy/test01.m ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
The error seems to be in NSDecimal handling. I suspect that this structure is just big enough to be split between registers and the stack, which may cause problems. Has anyone tested this on Linux/ x86-64? If the test doesn't fail there, then something strange is going on. David On 2 Apr 2009, at 13:54, Pete French wrote: ./runtest.sh base/NSProxy/test01.m not so good sadly... This is gnustep-make 2.0.8. Type 'gmake print-gnustep-make-help' for help. PASS: Proxy signed char PASS: Proxy unsigned char PASS: Proxy signed short PASS: Proxy unsigned short PASS: Proxy singed int PASS: Proxy unsigned int PASS: Proxy signed long PASS: Proxy unsigned long PASS: Proxy signed long long PASS: Proxy unsigned long long PASS: Proxy float PASS: Proxy float PASS: Proxy id PASS: Proxy enum PASS: Proxy NSRange PASS: Proxy NSPoint ./obj/test01: Uncaught exception NSInvalidArgumentException, reason: GSFFIInvocation: Class 'AUATUSH'(class) does not respond to forwardInvocation: for '(null)' gmake: *** [test] Abort trap: 6 (core dumped) FAIL: base/NSProxy/test01.m ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am Donnerstag, den 02.04.2009, 14:02 +0100 schrieb David Chisnall: > The error seems to be in NSDecimal handling. I suspect that this > structure is just big enough to be split between registers and the > stack, which may cause problems. Has anyone tested this on Linux/ > x86-64? If the test doesn't fail there, then something strange is > going on. I can confirm that a) the test also fail on x86_64-unknown-linux-gnu b) configure warns about *** Warning The mframe software has not been ported to x86_64. Using information from unknown. *** Warning The mframe software has not been ported to x86_64-linux-gnu. Using information from unknown/generic. c) the build warns about Compiling file mframe.m ... mframe.m: In function ‘mframe_build_signature’: mframe.m:160: warning: field precision should have type ‘int’, but argument 3 has type ‘long int’ (Though I'm not sure whether those warnings are relevant to the test suite failure yet). So I guess it's fair to say that gnustep currently does not fully support x86_64-unknown-linux-gnu yet. I'll try to look into it soonish if no one beats me to it. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am Freitag, den 03.04.2009, 11:19 +0200 schrieb David Ayers: > Am Donnerstag, den 02.04.2009, 14:02 +0100 schrieb David Chisnall: > > The error seems to be in NSDecimal handling. I suspect that this > > structure is just big enough to be split between registers and the > > stack, which may cause problems. Has anyone tested this on Linux/ > > x86-64? If the test doesn't fail there, then something strange is > > going on. > > I can confirm that > a) the test also fail on x86_64-unknown-linux-gnu > b) configure warns about > *** Warning > The mframe software has not been ported to x86_64. > Using information from unknown. > > *** Warning > The mframe software has not been ported to x86_64-linux-gnu. > Using information from unknown/generic. > > c) the build warns about > Compiling file mframe.m ... > mframe.m: In function ‘mframe_build_signature’: > mframe.m:160: warning: field precision should have type ‘int’, but > argument 3 has type ‘long int’ > > (Though I'm not sure whether those warnings are relevant to the test > suite failure yet). So I guess it's fair to say that gnustep currently > does not fully support x86_64-unknown-linux-gnu yet. Just to put this in perspective... passing complicated structs like NSDecimal by value (and that via an NSProxy) is not something that's done very often... so this failure shouldn't be overrated... even though I think it should be fixed. > I'll try to look into it soonish if no one beats me to it. > > Cheers, > David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
