Re: JS engine(s) provided by gnustep

[David Chisnall]

Hi,

As far as I know, no one has ported JavaScriptCore to GNUstep. It might not be 
a huge amount of work but that last time I looked at it (ten or so years ago) 
the build system for JSC conflated a lot of things in the Apple paths that 
would need disentangling if you want the Cocoa bits but ELF and the Linux 
calling conventions, for example.

If you don’t care about performance, there are a couple of small JavaScript 
interpreters (jsQuick and DukTape) that would be fairly easy to bridge to 
Objective-C. I played with using DukTape and GNUstep ages ago and it looked as 
if it would be quite easy to add an implementation of the APIs that JSC exposes 
on macOS, but it would give around 10% of the performance.

David

> On 9 Sep 2023, at 16:22, loserism  wrote:
> 
> 
> Hello friends.
> I'm trying to use JavaScriptCore through gnustep and found that gnustep 
> doesn't find JavaScriptCore, does anyone know how to fix it? I know I can use 
> other third party js engines, but I only want to use the interface provided 
> by Apple, does gnustep provide an implementation of this interface? Is there 
> an easy way to implement these interfaces that are not implemented or 
> provided in gnustep, other than implementing them myself?
> 
> Lastly, thanks for all the replies and help.
> Best regards.

Re: tools-windows-msvc runtime error

[David Chisnall]

Did you remember to disable incremental linking?

Last time I tested it, LINK.EXE did work, but if you had incremental linking 
enabled (I think it’s on by default?) then it inserts random padding into the 
Objective-C runtime’s metadata sections, which corrupt various things.

David

> On 18 Jul 2023, at 08:34, Frederik Seiffert  wrote:
> 
> Thanks, I reproduced the issue here. It turns out using the Microsoft linker 
> causes this issue, but using LLD works fine. I’m not sure why or since when 
> this is, as using link.exe definitely worked for me at one point, but now 
> using either VS 2019 or 2022 causes this crash as soon as objc_msgSend() is 
> called. Maybe David has an idea what could be going on here?
> 
> Anyway, passing -fuse-ld=lld should get you going. I would also add /Z7 to 
> produce debug symbols as well:
> 
> clang-cl -I C:\GNUstep\x64\Debug\include -fobjc-runtime=gnustep-2.0 -Xclang 
> -fexceptions -Xclang -fobjc-exceptions -fblocks -DGNUSTEP -DGNUSTEP_WITH_DLL 
> -DGNUSTEP_RUNTIME=1 -D_NONFRAGILE_ABI=1 -D_NATIVE_OBJC_EXCEPTIONS -DGSWARN 
> -DGSDIAGNOSE /MDd /Z7 /c test.m
> 
> clang-cl test.obj gnustep-base.lib objc.lib dispatch.lib -fuse-ld=lld /MDd 
> /Z7 -o test.exe /link /LIBPATH:C:\GNUstep\x64\Debug\lib
> 
> I’ve updated the toolchain readme to add this flag in the example.
> 
> Hope that helps.
> Frederik
> 
> 
>> Am 18.07.2023 um 03:00 schrieb loserist :
>> 
>> Sure! The following is it:
>> 
>> * thread #1, stop reason = Exception 0xc005 encountered at address 
>> 0x7ffcec4e1048: Access violation reading locatio
>> n 0x
>> * frame #0: 0x7ffcec4e1048 objc.dll`objc_msgSend + 40
>> frame #1: 0x7ff645cc1154 abc.exe
>> frame #2: 0x7ff645cc142c abc.exe
>> frame #3: 0x7ffcfb967614 kernel32.dll`BaseThreadInitThunk + 20
>> frame #4: 0x7ffcfc1826b1 ntdll.dll`RtlUserThreadStart + 33
>> Thanks!
> 
> 

Re: Newer features in Objective C

[David Chisnall]

On 13/02/2023 00:52, Gregory Casamento wrote:

Richard,

On Wed, Feb 8, 2023 at 09:57 Richard Stallman > wrote:


[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

GNU Objective C supports the features that Objective C had in 1989.
It would be nice to add the newer Objective C features.
Is anyone interested in doing that?
Please write to me personally if you sare intested in working on this.


This is not true.  Nicola Pero added declared properties a while ago, 
and exceptions were already there.  GCC is more or less feature-complete 
with respect to Objective-C circa 2005.  Apple subsequently invested 
quite a few person-years of engineering effort on adding more modern 
features, the largest of which is ARC.  Subscripting is a fairly simple 
transform, which would probably be quite easy to add to GCC.  Some of 
the other things, such as direct methods, require some careful design 
work (the interaction between +initialize and direct methods is annoying 
and I haven't yet come up with an ABI that would cause them to be a 
performance win).


I, personally, have the knowledge, but not the time.  I think that is 
the situation with a number of us, but I certainly don’t speak for us 
all.  We had hoped that someone in the existing GCC community might be 
willing to take this on if it’s to be done on a volunteer basis.


I have tried to persuade GCC folks to do this a few times, but there are 
a few problems:


 - The current Objective-C code in GCC is *awful*.  I started working 
on Objective-C support in clang because it was less work to add 
Objective-C codegen to clang *from scratch* than it was to add fairly 
simple features that it was missing at the time (declared properties) to 
GCC.  If anything, that code has become even harder to work with in the 
intervening years.


 - The license for GCC means that none of the companies that might have 
funded this work 10 years ago were willing to touch it.  This has not 
improved.


It’s my belief that this is a pretty large effort.  It will likely be 
multiple weeks or months of effort for one person to do as it involves 
adding a number of missing features.  In your email you say that GCC 
supports the features from 1989… that’s true but there are also SOME 2.0 
features that have been implemented but it is not complete so we have, 
in effect, Objective C 1.5. :)


That is *incredibly* optimistic.  Adding ARC support requires some very 
subtle work related to lifetimes and has a lot of interactions with 
other features (e.g. C++ copy constructors).  I would put the estimate 
in person-years, not less.


I am wondering if it might be necessary for the FSF to hire someone to 
do this outside of the community (or within if that’s an option).


I am not sure what the way forward on this is at this point.


I see two viable options:

 - Publicly acknowledge that GCC has not supported Objective-C for 15+ 
years, remove Objective-C support from the next release of GCC, and let 
GNUstep focus on working with compilers that do support the language.


 - Ensure that there is a pot of at least half a million dollars 
available to properly fund the work on GCC and contract an experienced 
developer to work on it full time for the next two years (or a company 
with a team of developers for a shorter period) and then be on retainer 
to fix the bugs going forward.


If the FSF has half a million to spend on Objective-C support in GCC 
then that money could be *far* better spent on improving other bits of 
GNUstep.


David

Re: Releases

[David Chisnall]

On 11/01/2023 10:40, Ivan Vučica wrote:
There’s the GPG signing part that makes Github Actions less useful. That 
is: whether you want to use Github actions depends on where you want to 
store this rather secret key. (We should rotate the GPG key anyway, by 
the way; the one we use for gnustep make/base/gui/back is still a 1024 
bit key, with no delegation to subkeys and no expiration dates set.)


This should be stored in a GitHub Secret and not stored on anyone's 
machine.  It is then exposed only to the release pipeline and 
compromising your dev VM does not leak it.



Besides, making the tarballs themselves is the easiest part.


It's not easy, it's free.  Every GitHub commit is automatically exposed 
as a tarball via a special URL, you don't need to do anything with it.




For the make/base/gui/back stuff, the hardest for me was going through 
the history, trying to make sense of everyone’s rather cryptic commit 
messages and rather lacking ChangeLog updates, identifying and 
summarizing the changes into something that might be useful to a reader, 
putting the changes into 2 different places, then generating the new 
release notes file.


For the runtime, I have an `ANNOUNCE` file containing markdown that is 
updated with things that will go in the release announcement as they're 
added.  I then just copy it to the release text.


What about win32? I never built win32 releases with NSIS, either. There 
have been improvements on building .msi packages on free platforms 
(GNOME’s msitools have gotten some GUI support!), but last time I 
checked, it was still not sufficiently similar to WiX Tools on Windows.


For the runtime, I use CMake's CPack support, which produces a zip file 
that can just be extracted on Windows and used.  It can also produce 
NuGet packages if you want to manage dependencies like that.  GNUstep 
Make makes all of this much harder (running GNUstep Make on Windows at 
all is sufficiently painful that I've never managed it successfully).


David

Re: Releases

[David Chisnall]

On 10/01/2023 19:42, Frederik Seiffert wrote:
I’m not familiar with what needs to be done for releases (can you share 
a link to that Google Doc maybe?), but I’m wondering if released could 
be mostly automated on the GitHub Actions CI.


This is on my to-do list for the runtime.  It's something that we're 
doing with other projects and it means that the release process is just 
creating a tag.  This then builds releases for any targets that we want 
to ship binaries for, creates the GitHub release, pushes the built 
artefacts to the release, and adds a new commit on the main branch 
rolling over versions and so on.


David

Re: No more support for GNUstep on FreeBSD

[David Chisnall]

On 26/10/2022 23:22, Riccardo Mottola wrote:

I suppose you refer that you dropped the FreeBSD packages, but you do
still maintain the runtime itself aso on FreeBSD and run the base test
suite at least, right?


I still maintain the runtime and have CI set up for Linux, Windows, and 
FreeBSD.  This is currently limited to x86[-64], but I hope to extend it 
to using QEMU user mode for some other architectures soon.


I haven't looked recently, I assumed -base also had CI set up for 
FreeBSD, since there are several free providers for F/OSS projects.  If 
we depend on people manually running the test suite, I can probably do 
that periodically.  I try to run it before I push anything to the 
runtime that might impact Foundation implementations.


David

Re: No more support for GNUstep on FreeBSD

[David Chisnall]

Hi,

I dropped maintainership because I haven't actually used GNUstep or run 
FreeBSD on machines with displays for a while, so I wasn't able to test 
things well and didn't feel comfortable updating ports and claiming that 
they worked.  I am happy to help anyone who wants to update the ports. 
I believe that they should still work.  We test the runtime in CI on 
FreeBSD, at least.


I believe there is a new upstream for libdispatch, but I've not tried it.

David

On 25/10/2022 16:14, bruce wrote:
I’m restarting a project of mine; it took some time to replace my dev 
computer when it died. But now that I've gotten a new pc,I find GCD 
(libdispatch) is no longer available on FreeBSD.  The Freshports page, 
https://www.freshports.org/devel/libdispatch/ 
, shows the reason is the 
port expired on 5/5/2020, so when I reinstalled it was no longer 
available. It states that the build was broken for more than 6 months, 
and when I look at the GNUstep entry, there is no longer a maintainer 
for GNUstep on FreeBSD.



Are there plans to reinstate support for FreeBSD? I can cope with 
GNUsteps out of date documentation, but this lack of support is a hard 
stop for my project.



bruce

Re: Using clang-format for formatting our code

[David Chisnall]

On 16/08/2022 11:18, Richard Frith-Macdonald wrote:




On 16 Aug 2022, at 10:25, Hugo Melder  wrote:

Hi,

Having a consistent code style is useful both for reading and writing code, 
especially for contributors. The GNUstep base framework currently has a 
.clang-format configuration file in the project root, but is not used. We could 
use a configuration file from major Objective-C open source projects like 
WebKit, or define our own formatting guidelines.

What is your opinion towards strict code formatting?


We have a coding/formatting style defined in the GNUstep base documentation 
(coding-standards.texi), and we try to make everything conform to that standard.

However, I prefer *not* to refuse contributions based on stylistic deviations.  
 Rather I would prefer to thank the contributor, correct any issues, and 
encourage use of the standard format in future contributions.

If the .clang-format could be fixed to implement the GNUstep coding style, it 
might be useful for those of us who have it installed.



From using clang-format in some other projects:

 - Having a machine-applied style is a huge improvement, it avoids any 
discussion of style in code review (aside from naming of things. 
clang-tidy can help a bit there) and is a big win for folks who are 
moving between projects with different styles.


 - There's some initial pain for anyone downstream after the first time 
that you apply it, but this is reduced later on.  Some editors will 
automatically format things with a .clang-format style and this can 
cause downstream people to introduce accidental diffs if a .clang-format 
exists and isn't used.


 - Different versions of clang-format produce slightly different 
output.  It's worth picking a version and keeping it as the default for 
a few years and then moving forward.


 - Enforcing clang-format compliance on PRs with github actions is easy 
and means that you never have to review inconsistently formatted code.


David

Re: Automated Reference Counting (Was: Disappointed by GNUstep)

[David Chisnall]

On 08/02/2022 12:40, Richard Frith-Macdonald wrote:

On 8 Feb 2022, at 11:01, David Chisnall  wrote:
   I could write significantly simpler code that ran faster using Objective-C++ 
and ARC than I could without either and GNUstep would not accept the less-buggy 
and faster option.  Refactoring code to make it less maintainable so that it 
could compile with an old compiler and spending time finding bugs that are 
impossible by construction with ARC felt like a complete waste of my time.

Well that could be a bit misleading: while GNUstep policy has not accepted 
breaking the portability of existing code it has never prohibited the addition 
of new non-portable features (though obviously portable is preferred).


The granularity for enabling ARC is per compilation unit, which meant 
that it could be used for entirely new classes, but not for much else, 
and even then some of the private GNUstep headers are not ARC-safe (e.g. 
GSIMap.h) and so you'd end up with two completely segregated worlds 
within the same codebase.


David

Re: Automated Reference Counting (Was: Disappointed by GNUstep)

[David Chisnall]

On 07/02/2022 20:21, Fred Kiefer wrote:

Yes, ARC is a real improvement for application code. Not so much for libraries, 
as GNUstep is. Getting reference counting correct in procedural programming is 
not too hard in most case, but doing so declaratively just seems easier. You 
need to be very careful and provide the correct hints for the compiler to sort 
out things for you. I would expect that a switch here will cost us about two 
years until we got most of the declarations correct. Still the change would be 
worthwhile.

I think you're making up an artificial difference here. The rules for reference 
counting are the same for both application and libraries: If you own/use an 
object retain it, once you no longer own/use it (auto)release it. The tricky 
point just is avoiding cyclic references because they will never be released.
But the real problem (usually) starts when programmers start trying to outsmart those 
simple rules by thinking that some object is already retained by some other 
container/instance variable and they can save some extra CPU cycles (plus the textual 
clutter) by omitting the retain/release calls. And I know what I'm talking about because 
I often enough fall prey to this sort of "optimization". But, as the issue with 
NSPopUpButtonCell shows, I'm not the only one. Note that there is no semantic reason to 
use an unretained reference for the _selectedItem instance variable.
So for -gui the main issue is managing references between objects and their 
delegates and avoiding cyclic reference between parents and children in the 
view hierarchy. And otherwise not compromising the code by the attempting to 
omit retain/release otherwise. For -base, the difficulty is not so much cyclic 
references, but multithreading. You have to be even more careful about 
retaining objects because -- at least without serious locking, which comes with 
its own set of problems -- you cannot be sure that assumptions that hold at 
entry of a method are still valid at the end. So, in a way I feel its even the 
other way around: In libraries ypu should be very sure about proper management 
of ownership, which is better done automatically, whereas in applications you 
can eventually be more sloppy, for instance when you know that the application 
is single threaded.

What you are describing is about what I wanted to say, but obviously failed to 
do. Things are a lot easier in an application as you know what you are aiming 
at. In a library you need to be correct for whatever use case people come up 
with. Doing that is hard. ARC may be able to help you in most cases. Still you 
will have to be very careful and you will need a lot more understanding of the 
implicit semantics. I agree that we should be going that route, we just need to 
be aware that it is a steep road and we need to be careful. Just as you said.


If anything, ARC is more important for libraries than application code, 
for precisely this reason.  ARC explicitly defines ownership (strong, 
weak, unsafe_unretained) for consumers of a library interface.  Things 
like delegates become weak references and so this is both explicit in 
the API (the AppKit component does not own the delegate) and less error 
prone (the reference becomes nil if the object is deallocated).


When Apple moved their Foundation and AppKit implementations to ARC, 
they reported that they had less source code, smaller binaries, faster 
code, and fewer bugs.  The compiler does a lot of the 
reference-count-elision things for you and it's easier to define APIs 
that return strong references and don't leak, so you can significantly 
reduce autorelease pool pressure.


Many years ago, I ran the -base and -gui code through the ARC Migration 
Tool (built into clang).  I think about half of the code worked with ARC 
already, a lot of the files needed some small tweaks.  The migration 
tool pointed out all of the places where it couldn't do the automatic 
translation.


ARC also makes it a lot easier to interop with C++.  C++ containers can 
store Objective-C object pointers in ARC mode and will treat the retain 
/ release calls as copy constructors and destructors.  WinObjC made 
heavy use of this and the last time I tried it replacing 
`NSMutableDictionary` with a thin wrapper around 
`std::unordered_map` (with a hash function defined to call `-hash` 
and the equality function defined to call `-isEqual:`) it was faster 
than GNUstep's implementation in my tests.  I didn't try the same thing 
with `NSMutableArray` and `std::vector`.  I'm told that Apple's 
implementations do this: implement the containers in C++, wrap them in 
Objective-C (and there are a lot of high-performance C++ containers with 
friendly licenses that we could use if the standard library ones aren't 
adequate).


This was a big part of the reason that I gave up contributing to 
GNUstep.  I could write significantly simpler code that ran faster using 
Objective-C++ and ARC than I could without either and 

Re: Building GUI with libobjc2 for Windows MSVC

[David Chisnall]

On 27/10/2021 11:39, Frederik Seiffert wrote:

So I tested this some more, and after rebuilding libs-base as a whole (I had 
previously only rebuilt the relevant files) I’m getting the following linker 
errors:


lld-link: error: : undefined symbol: Q^?LL}
lld-link: error: : undefined symbol: ^{autorelease_array_list}II[0☺]}
lld-link: error: : undefined symbol: 
^{_NSZone}QQ^{_GSIMapBucket}^{_GSIMapNode}Q^^{_GSIMapNode}Q}
lld-link: error: : undefined symbol: ciiC[38C]}
lld-link: error: : undefined symbol: {_RTL_SRWLOCK=^v}ALIi}
lld-link: error: : undefined symbol: ^v}
lld-link: error: : undefined symbol: ^?^?^?^?^?^?^?Q☺^{_NSZone}}
lld-link: error: : undefined symbol: 
^{_NSNotificationQueueRegistration}^{_NSNotificationQueueRegistration}}
lld-link: error: : undefined symbol: ☺I^☺ii}
lld-link: error: : undefined symbol: i☺☺}
lld-link: error: : undefined symbol: 
[16{_SETJMP_FLOAT128=[2Q]}]^{_NSHandler}☺}
lld-link: error: : undefined symbol: QQ}
lld-link: error: : undefined symbol: 
^{_xmlDoc}^{_xmlDtd}^{_xmlEntity}^{_xmlNode})
lld-link: error: : undefined symbol: ☺☺{?=b0I1b1I31}}
lld-link: error: : undefined symbol: b0I1b1I1b2I1b3I1b4I1b5I1b6I1b7I1b8I1}



I’m not sure if they indicate an issue with the patch, or if it’s rather an 
issue e.g. with how I built Clang or how I’m using the custom build? I used the 
LLVM_ENABLE_PROJECTS=clang CMake option to build Clang, but maybe I need to 
enable other LLVM projects like lld, libcxx or others too?


These look as if they're still clang bugs.  All of these look like they 
are fragments of Objective-C type encodings. The second one, for 
example, is a pointer to a *almost* all of the type of the 
autorelease_array_list structure: the next pointer, the size, the count, 
and a zero-sized array of the rest.  It's missing the open brace and the 
name of the structure though.


Since all of them end with a close brace, I suspect that there's 
something in the field names that isn't a valid PE/COFF symbol name (at 
least for dllexported things, not sure if the restrictions are different 
here).  The second one was the easiest to find, since only one class in 
GNUstep looks like it implements this (note: *something* is wrong in 
your build environment because I don't think we should be seeing that 
version when targeting an ARC-enabled runtime and the one fourth from 
the button looks as if it's trying to use the old NeXT-style exceptions 
rather than SEH, but it helps find the bug so let's leave it for now).


The generated variable should be:

__objc_ivar_offset_NSAutoreleasePool._release.^{autorelease_array_list=^{autorelease_array_list}II[0\01]}

So it looks as if it's being truncated at the first equals sign?  I 
wonder if equals is not permitted in dllexported symbols?  This doesn't 
seem to cause problems for DLL-local symbols on Windows.


In clang/lib/CodeGen/CGObjCGNU.cpp, you'll see this line:

// Prevent the @ from being interpreted as a symbol version.
std::replace(TypeEncoding.begin(), TypeEncoding.end(),
  '@', '\1');

Underneath it, can you add this:

std::replace(TypeEncoding.begin(), TypeEncoding.end(),
  '=', '\2');

Let me know if that fixes things.  If so, it's an ABI break on Windows, 
so it probably needs to be guarded on whether the symbol is dllexported 
and may need an explicit opt-in flag.


Alternatively, it may be an lld bug - if you use link.exe instead of 
lld, does it work?  Most of my Windows testing was done with link.exe 
(with incremental linking disabled).


David

Re: Building GUI with libobjc2 for Windows MSVC

[David Chisnall]

Hi,

If you can comment on the review and approve it, I can commit it (once I’ve 
fixed the clangformat warnings).

David

> On 23 Oct 2021, at 16:33, Frederik Seiffert  wrote:
> 
> Hi David,
> 
>> Am 14.10.2021 um 13:59 schrieb David Chisnall :
>> 
>> I believe this patch should fix it:
>> 
>> https://reviews.llvm.org/D111792
> 
> Thank you, this worked great after I built Clang 13 with this patch applied!
> 
> What’s the process for getting this merged, and and any idea when we could 
> expect official builds with it?
> 
> Frederik
> 
> 

Re: Regular expressions

[David Chisnall]

Apple’s docs are here:

https://developer.apple.com/documentation/foundation/nsregularexpression

The docs basically say ’this is a very thin wrapper around ICU’s regular 
expression code’, so the GNUstep code (which also wraps ICU) should be 
completely compatible.

David

> On 17 Oct 2021, at 19:20, lars.sonchocky-helld...@hamburg.de wrote:
> 
> I dunno, maybe it’s not documented, but the sources are here:
> 
> https://github.com/gnustep/libs-base/blob/master/Source/NSRegularExpression.m
> 
> https://github.com/esteve/gnustep-base/blob/master/Headers/Foundation/NSRegularExpression.h
> 
> cheers,
> 
>   Lars
> 
>> Am 17.10.2021 um 20:16 schrieb Daniel Santos :
>> 
>> Hi,
>> 
>> Where can I find the documentation for that class ? I am looking at 
>> http://www.gnustep.org/resources/documentation/Developer/Base/Reference/Base.html
>> and it seems its not there.
>> 
>> Thanks,
>> Regards
>> Daniel Santos
>> 
>> 
>> 
>>> On 17 Oct 2021, at 08:34, Richard Frith-Macdonald 
>>>  wrote:
>>> 
>>> 
>>> 
 On 16 Oct 2021, at 14:37, Daniel Santos  wrote:
 
 Hi,
 
 Does GNUStep have some library for handling regular expressions ?
 
>>> 
>>> See the NSRegularExpression class in the GNUstep-base library.
>>> It wraps the regular expression support of ICU.
>>> 
>> 
> 

Re: Building GUI with libobjc2 for Windows MSVC

[David Chisnall]

On 14/10/2021 07:28, Frederik Seiffert wrote:
Am 13.10.2021 um 19:13 schrieb David Chisnall 
mailto:gnus...@theravensnest.org>>:


I believe that this is a bug in clang.  If the class is dllexported 
then the ivar offset variables for public / protected ivars should be 
dllexported as well.  I think I missed that case when doing the 
Objective-C support for Windows - I'll take a look tomorrow.


Thanks. I tried explicitly marking these variables as @public in Base 
but are getting the same error.


I believe this patch should fix it:

https://reviews.llvm.org/D111792

Please can you test and report back?

David

Re: Building GUI with libobjc2 for Windows MSVC

[David Chisnall]

On 13/10/2021 16:08, Frederik Seiffert wrote:

Hi all,

I’ve started looking into building libs-gui for Windows using libobjc2 and the 
MSVC ABI, and I’m down to one linker error that I’m unsure how to deal with:


lld-link: error: undefined symbol: __objc_ivar_offset_NSFileWrapper._icon.☺

referenced by NSFileWrapperExtensions.m:42
   
NSFileWrapperExtensions.m.o:(_i_NSFileWrapper_NSExtensions_setIcon_)


It seems that GUI defines an NSFileWrapper category that accesses an instance 
variable defined in Base here, and that results in this linker error. The class 
definition in Base is correctly annotated with __declspec(dllexport).


I believe that this is a bug in clang.  If the class is dllexported then 
the ivar offset variables for public / protected ivars should be 
dllexported as well.  I think I missed that case when doing the 
Objective-C support for Windows - I'll take a look tomorrow.


By the way, I've been using vcpkg for another project (on FreeBSD) - 
it's probably the best way of getting the dependencies for any libraries 
that GNUstep depends on for the MSVC ABI.  It has good CMake integration 
but can probably be made to work with GNUstep Make (though if you have a 
CMake build system for GNUstep, it should work very nicely).


David

Re: RISC-V Support for GNUstep

[David Chisnall]

On 07/10/2021 18:19, lars.sonchocky-helld...@hamburg.de wrote:

well, I didn’t consider if you (and others) are aware of RISC-V


Page two of the RISC-V spec says:

> Contributors to all versions of the spec in alphabetical order 
(please > contact editors to suggest corrections): ... David Chisnall ...


So, it's probably a fair assumption that I'm aware of it.

David

Re: RISC-V Support for GNUstep

[David Chisnall]

Hi,

QEMU is fast enough for development (that's how I did the AArch32, 
AArch64, and MIPS bring-up for libobjc2).  I haven't written the 
assembly code paths for RISC-V because I don't have sufficient time + 
interest.  I'm happy to review patches.


If I have time, I'd like to refactor the existing objc_msgSend code into 
a set of platform-specific macros and a generic implementation, which 
should make porting to new architectures a bit easier.


David

On 07/10/2021 17:46, lars.sonchocky-helld...@hamburg.de wrote:

Hi fellow GNUsteppers,


I am thinking about purchasing a HiFive Unmatched 
https://www.sifive.com/boards/hifive-unmatched 
 board for helping to 
port GNUstep and especially the GNUstep ObjC runtime to RISC-V.


But first I would need to know if there is interest in porting GNUstep 
to RISC-V.


If so, I would buy such a board and connect it to the network with ssh 
access for those doing the porting. Sorry for doing it this way, I am 
just not fit enough to port things like 
https://github.com/gnustep/libobjc2 
 on my own.


Please reply if you have the skills to help porting GNUstep and want to 
help porting GNUstep to RISC-V.



kind regards,

Lars

Re: Project-Center 0.6.2

[David Chisnall]

Hi,

This code looks correct.  It’s entirely possible that this is a bug in the 
runtime.  Which runtime / ABI are you using?

David

> On 30 Sep 2021, at 17:50, Daniel Santos  wrote:
> 
> Hi,
> 
> I am adding some changes to this, and have a question : 
> I am trying to add a method to PCProjectManager.h and .m.
> The code compiles because I can see some warnings go by in the make phase.
> But at runtime that selector (named : -(void)newProjectFromSources: 
> (id)sender; )
> is not on the selector list that I am obtaining with :
> 
>  NSLog([NSString stringWithCString: class_getName([projectManager class])]);
> 
>  unsigned int amountMethod = 0;
>  Method *methods = class_copyMethodList([projectManager class], 
> );
>  unsigned int i;
>  for (i = 0; i < amountMethod; i++) {
>Method method = methods[i];
> 
>printf("\t method named:'%s' \n", sel_getName(method_getName(method)));
>  }
> 
> What am I doing wrong ? or not doing ? I made a ‘make clean’ and even deleted 
> the ProjectCenter.app directory.
> Another method I added to the class PCMenuController that is called by a menu 
> item works and calls the above code.
> 
> Thanks
> Regards
> Daniel Santos
> 
> 
> 
> 
> 

Re: Attempting migration from travis-ci.org -> travis-ci.com

[David Chisnall]

I'd second the suggestion to go with GitHub Actions.  With the vmactions 
thing, you can do FreeBSD/OpenBSD/NetBSD/Solaris CI on the free Mac 
runners.  It looks as if native FreeBSD support isn't too far away.


David


On 09/07/2021 09:52, Niels Grewe wrote:

Hey folks,

I have no particular knowledge of the travis org/com migration thing. Back when 
I set upthe CI pipeline, travis-ci was one of the very few options available. 
Nowadays, I‘d definitely pick Azure Pipelines over travis-ci. But GitHub 
Actions might be worth looking at if a migration is inevitable. It‘s always 
shell scripts in a YAML sandwich anyways.

Best,

Niels

--
Sent on the road


Am 09.07.2021 um 10:29 schrieb David Chisnall :

On 08/07/2021 13:35, Gregory Casamento wrote:

I am seeing the following message when trying to migrate.   David, do you own 
these configs on travis?



I don't think I own (or have ever touched) any of the Travis things. Niels set 
this up.  For the runtime, I use Azure Pipelines for Windows / Linux / macOS 
tests, Cirrus CI for FreeBSD.

David

Re: Attempting migration from travis-ci.org -> travis-ci.com

[David Chisnall]

On 08/07/2021 13:35, Gregory Casamento wrote:
I am seeing the following message when trying to migrate.   David, do 
you own these configs on travis?



I don't think I own (or have ever touched) any of the Travis things. 
Niels set this up.  For the runtime, I use Azure Pipelines for Windows / 
Linux / macOS tests, Cirrus CI for FreeBSD.


David

PSA: -f[no-]objc-encode-cxx-class-template-spec

[David Chisnall]

Hello everyone,

Clang now provides an option -fobjc-encode-cxx-class-template-spec / 
-fno-objc-encode-cxx-class-template-spec to specify whether encodings 
that include C++ types with template parameters should be mangled in 
full or abbreviated to ^v.  This is an ABI-breaking flag for the GNUstep 
ABI, where type encodings are used both in dispatch lookup and in ivar 
offset variables.  If you have an Objective-C++ codebase that uses a lot 
of template instantiations, this will give you smaller binaries.  It is 
safe to use *only* if you do not expose ivars or methods in your public 
headers that include templated C++ types.


For example, this is safe:

public_header.h
```obj-c
@interface UnorderedStringMap
- (id)objectForKey: (NSString*)aKey;
@end
```


private.m:
```obj-c
@implementation UnorderedStringMap
{
@private
std::unordered_map map;
}
- (id)objectForKey: (NSString*)aKey
{
return map[aKey];
}
@end
```

This is not:

public_header.h

```obj-c
@interface UnorderedStringMap
{
@public:
// ivar can't be found if the flag differs between two compilation units
std::unordered_map map;
}
- (id)objectForKey: (NSString*)aKey;
// Method can't be called if the flag differs between two compilation units.
- (void)resetMap: (std::unordered_map&&)aMap;
@end
```

If you use Objective-C++ internally but expose only Objective-C 
interfaces, then you may find this flag useful.



David

Re: OpenBSD crashes - GWorkspace coredumps - mismatched C++ libraries

[David Chisnall]

Hi Riccardo,

On 21/05/2021 15:14, Riccardo Mottola wrote:

So indeed, once running, there is a mix of:

     0f88c000 2f96f000 rlib  0    1   0 
/usr/local/lib/libestdc++.so.19.0


vs:
     08fb7000 28fbd000 rlib  0    2   0 /usr/lib/libc++.so.7.0
     0ca18000 2ca1c000 rlib  0    3   0 /usr/lib/libc++abi.so.5.0


That is, indeed, the problem.  You can mix libc++ and libstdc++ (though 
the types cannot cross a library boundary) but both libc++abi and 
libsupc++ expose the same symbols and cannot be mixed.  By default, 
libstdc++ statically links libsupc++.  On FreeBSD, we avoid this by 
linking both libc++ and libstdc++ against the system-provided libcxxrt. 
 It looks as if OpenBSD (at least with your egcc build) doesn't do this.


but why do base and FSNode link against this system library? Do we use 
C++ stuff? not that I know, explicitely. Only PDFKit has an explicit use 
of the C++ compiler.


We need to hook into the C++ runtime library to ensure that 
Objective-C++ exceptions work.  You need to either:


 - Compile and link the C++ library (PDFKit) against the system C++ 
implementation (libc++ / libc++abi), or
 - Compile and link the Objective-C runtime against the extra c++ 
runtime (libestd++).  Note that libestdc++ is an unusual name and so 
won't be found by default, you will need to pass this as an explicit 
option in the libobjc2 build (ccmake will show you the name).


David

Re: GNUstep on Windows using Clang + MSVC ABI

[David Chisnall]

Thanks,

I’m taking next week off for Easter - hopefully I’ll have some time to look at 
both of these then.  I don’t think either is much work to fix, if I can easily 
set up the test environment.

David

> On 22 Mar 2021, at 16:53, Frederik Seiffert  wrote:
> 
> Hi David,
> 
>> Am 02.02.2021 um 12:29 schrieb David Chisnall :
>> 
>>>>> lld-link: error: relocation against symbol in discarded section: 
>>>>> __start_.objcrt$SEL
>>>>> >>> referenced by C:\msys64\tmp\conftest-78a937.o:(.objc_init)
>>>>> This is reproducible when building a file that calls ObjC runtime 
>>>>> functions but doesn’t actually contain any ObjC code. Not sure if that’s 
>>>>> expected behavior or bug.
>>>> 
>>>> I think this is a bug, probably a clang bug (and probably my fault)
>>> Should I open an LLVM issue for this?
>> 
>> Yes please.  There was an identical bug on ELF platforms, I may have failed 
>> to fix it for Windows.
> 
> Here you go, please let me know if you need any other info:
> https://bugs.llvm.org/show_bug.cgi?id=49681
> 
>>>> Awesome work, and it makes me much happier than trying to support MinGW.
>>> Thank you, glad you like it! This is also exciting to us because it should 
>>> e.g. allow us to use recent Windows technologies like the C++/WinRT 
>>> language projection from ObjC++ which are not compatible with MinGW.
>>> That being said, I would still very much like to get libobjc2 working with 
>>> MinGW as well, as it would allow people currently using GNUstep with GCC in 
>>> a MinGW environment to switch to Clang/libobjc2, should result in a more 
>>> streamlined setup experience with all dependencies being available via 
>>> MinGW packages and everything being built in one shell, and allow for 
>>> existing MinGW-based software to be used.
>>> I’ll try to get you those instructions for building LLVM with the MinGW 
>>> patches in the next couple weeks.
>> 
>> I'll try to find some time to work on it.
> 
> I’ve finally found steps to reproduce the issues with MinGW using a "normal" 
> (non-MinGW) LLDB build using a CMake toolchain file:
> https://github.com/gnustep/libobjc2/pull/190#issuecomment-792676170
> 
> Hopefully that will be sufficient to look into these at some point.
> 
> Thanks!
> Frederik
> 

Re: ANN: GNUstep Windows MSVC Toolchain Scripts

[David Chisnall]

On 20 Mar 2021, at 10:49, Frederik Seiffert  wrote:
>> If you look at the build for libobjc2 on Windows, because we're using a 
>> CMake version that predates official support for either Objective-C or using 
>> the gcc-compatible driver, we have the same problem with /TP being added.  
>> We work around this with an undocumented feature of clang where you can 
>> provide an environment variable that removes flags from the command line.  
>> You can probably set that in your Visual Studio build. Setting this strips 
>> the TC and TP flags from clang invocations:
>> 
>> CCC_OVERRIDE_OPTIONS=x-TC x-TP x/TC x/TP
> 
> Good idea using CCC_OVERRIDE_OPTIONS, that should probably work fine. 
> Ultimately I’m hoping that we can come up with something more integrated like 
> a custom build tool spec in VS, so .m and .mm files automatically get all the 
> right flags.

It’s definitely not the *right* solution, but it should work for now.  VS Code 
now has really good CMake support and I think it’s reasonable in VS as well.  
I’d love to see GNUstep adopt CMake - with the last release, it officially 
supports Objective-C and using clang with the gcc-like driver on Windows, so it 
would give us the ability to generate XCode projects, Visual Studio projects, 
and something that VS Code supports natively.

>> It would be great at some point to remove the pthread-w32 dependency. 
>> SRWLocks and ConditionVariables on Windows seem to provide everything we 
>> need for NSLock* and be a fairly small amount of code.
> 
> Yeah absolutely, I just wanted to make sure we could actually get this 
> working before spending time on improvements. I also expect to spend a lot of 
> time on fixes while integrating the toolchain in our project.

The SRWLock APIs were introduced with Windows 7, as I recall.  Last time I 
looked at this, there were enough XP machines that folks cared about that it 
didn’t make sense to use them, but now Windows 7 is effectively out of support 
so is a reasonable baseline.

David

Re: ANN: GNUstep Windows MSVC Toolchain Scripts

[David Chisnall]

That's great news, congratulations!

If you look at the build for libobjc2 on Windows, because we're using a 
CMake version that predates official support for either Objective-C or 
using the gcc-compatible driver, we have the same problem with /TP being 
added.  We work around this with an undocumented feature of clang where 
you can provide an environment variable that removes flags from the 
command line.  You can probably set that in your Visual Studio build. 
Setting this strips the TC and TP flags from clang invocations:


CCC_OVERRIDE_OPTIONS=x-TC x-TP x/TC x/TP

It would be great at some point to remove the pthread-w32 dependency. 
SRWLocks and ConditionVariables on Windows seem to provide everything we 
need for NSLock* and be a fairly small amount of code.


David

On 17/03/2021 21:39, Frederik Seiffert wrote:

I am pleased to announce a new GNUstep project containing a set of scripts to 
build GNUstep for Windows with Clang and libobjc2 using the Visual Studio 
toolchain and MSVC ABI (i.e. without MinGW):

https://github.com/gnustep/tools-windows-msvc

The scripts currently build GNUstep Base with all dependencies, plus also 
libdispatch. Invoking build.bat from an x86 or x64 Visual Studio developer 
command prompt will build all libraries for that architecture for both debug 
and release CRT libraries. Each library is either build directly in the Windows 
shell (libobjc2, libiconv, libxml2, libxslt), or an MSYS2 Bash shell is spawned 
for libraries requiring such an environment (libffi, GNUstep Make/Base).

I only found usable pre-built binaries for Pthread-win32 and ICU (and no good 
way to integrate NuGet packages), so all the others are built from source. 
Since building for MSVC is far from standard for projects coming from Unix (but 
fortunately always supported in some way it seems), each of them requires their 
very own special setup, and required a lot of massaging to get everything 
working.

The resulting set of DLLs should be usable to integrate Objective-C code in 
basically any Windows app that is not using MinGW, using either clang or 
clang-cl to build ObjC code. The Readme contains some info on the required 
compiler and linker flags. Hopefully down the line we can also get other 
GNUstep libraries on board as to offer a more complete GNUstep package for 
Windows MSVC.

(I also took a brief stab at trying to build Objective-C code in Visual Studio, 
but unfortunately it adds a /TP flag forcing clang-cl to treat the input as C++ 
(just like CMake). I’m guessing there are ways around this as WinObjC was able 
to integrate ObjC files in VS, which we can hopefully figure out some time.)

While many tests in Base are still failing for various reasons, I plan on 
spending more time on this in the coming months and will also try to add MSVC 
to the Travis CI setup so we can ensure the configuration stays supported. I 
already set up CI via GitHub Actions for the scripts themselves (not running 
any tests atm.). (And btw. GitHub Actions runners seem *much* faster than 
Travis CI.)

Thank you all and especially David for helping me get this working, and bearing 
with me through all my messages to the mailing list on this topic over the last 
year! I’m looking forward to see what comes out of this effort.

Frederik

Re: GNUstep on Windows using Clang + MSVC ABI

[David Chisnall]

On 09/02/2021 16:20, Richard Frith-Macdonald wrote:




On 29 Jan 2021, at 16:28, David Chisnall  wrote:




  We have given up supporting MinGW for snmalloc and I am considering 
optionally supporting snmalloc for Objective-C object allocations since it is 
much faster than the system malloc on most platforms and is particularly good 
for fixed-size allocations as are common in Objective-C.  It would be a shame 
for this to be an everywhere-except-Windows thing.


Hi David,  I am giving snmalloc a try, but I'm wondering if (and why) you think 
it is actually better than mimalloc?


Well, I am biased as one of the authors of snmalloc...


As far as I can tell mimalloc ticks the general performance boxes and is 
admirably small (ie relatively simple code).
My interest is probably unusual in that it's primarity about maintaining a low 
memeory footprint for long running processes rather than about speed, so if 
snmalloc does a better job of avoiding fragmentation it would be very appealing.


I think mimalloc may do slightly better there.  We've adopted a lot of 
techniques from mimalloc and snmalloc was doing better than mimalloc 
last time we benchmarked.  The main difference between the two is that 
mimalloc frees directly back into the chunks using atomic operations, 
whereas snmalloc has a per-thread message queue that receives freed 
allocations, making the alloc and free operations entirely thread-local.


From my incredibly biased perspective:

Snmalloc is C++ with clean abstractions and using template parameters 
for a lot of the policy, which lets it both be very flexible and also 
compile down to tiny amounts of code (around 10 x86 instructions on the 
fast path for malloc).  Mimalloc is a C codebase.


Snmalloc has very clean architecture and platform abstractions.  We 
support a lot of both, including things like Haiku and running inside an 
SGX enclave with OpenEnclave.  The mimalloc OS abstraction layer has a 
lot of ifdefs interleaved with code:


https://github.com/microsoft/mimalloc/blob/master/src/os.c

The snmalloc equivalent is a platform-abstraction layer where we define 
a class for each platform.  Some of these are simple, for example 
OpenBSD just says to use the generic POSIX paths:


https://github.com/microsoft/snmalloc/blob/master/src/pal/pal_openbsd.h

Others are a bit more complex, with Windows providing its own codepaths:

https://github.com/microsoft/snmalloc/blob/master/src/pal/pal_windows.h

This abstraction layer if even sufficiently flexible that we can run 
inside the FreeBSD kernel with a handful of lines of code:


https://github.com/microsoft/snmalloc/blob/master/src/pal/pal_freebsd_kernel.h

We're also able to tune aggressively for size class.  If we know the 
size statically at compile time, or if we know it at free time, then we 
can be more accurate.  For Objective-C, I'd like to steal one bit form 
the isa pointer or refcount to see if we've use the extraBytes argument 
in class_createInstance and, if not, use the snmalloc API that doesn't 
need to look up the size.  This should save two instructions and one or 
two cache lines in the free path for most Objective-C dealloc operations.


We originally built snmalloc for Verona, where we expect to do a lot of 
allocations on one thread and the corresponding frees on another thread. 
 A lot of producer-consumer workloads have this characteristic and 
we've seen some incredible speedups reported for snmalloc over jemalloc 
on workloads like this and generally a modest improvement over mimalloc.


We are doing all of the CHERI temporal safety work on top of snmalloc. 
It is the building block for a fully memory-safe C/C++ environment.  As 
a side effect of this (and of the fact that it's a C++ codebase), we've 
been adding smart-pointer types for all of the different kinds of 
pointer (e.g. pointers into free lists, pointers handed out to the 
malloc consumer).  We are about to start a security audit and this makes 
if *far* easier for anyone to reason about the correctness of our code 
than in a C codebase.


We've also done a lot of work to support sandboxing within an address 
space with snmalloc.  This isn't quite finished but it gives us a very 
cheap way of allocating sandbox memory from either inside or outside a 
sandbox that can then be freed on the other side of the boundary 
cheaply.  This is important for the Verona foreign-code model, which is 
built entirely on top of sandboxing.


All of that said, mimalloc is also evolving and was the source of 
several ideas that improve performance.  My favourite was initialising 
the TLS for the allocator with a dummy allocator and then replacing it 
only on the slow paths.  This took an extra 'has malloc been 
initialised' branch of the fast path for every allocation.


Note that any comparison of total memory usage for snmalloc should be 
done with a system under memory pressure.  On *NIX platforms that 
support some variant of `MADV_FREE`, we use

Re: libobjc2 on OpenBSD 6.8 build errors - C++ runtime not found

[David Chisnall]

Hi,

> On 2 Feb 2021, at 14:22, Riccardo Mottola  wrote:
> 
> Hi,
> 
> while I need to find some time to reply about NetBSD issues, I wanted to test 
> current  base/gui/back on OpenBSD before our release and as I was also test 
> latest libobjc2. Since I had pending to upgraded to latest OpenBSD 6.8, I did 
> that too.
> 
> Before upgrading, I did build libobjc2 on 6.7 which had an older clang: it 
> did build and 95% of the test passed (the failures being similar to 
> NetBSD/amd64 btw). After that I proceeded upgrading my system, userland, 
> packages and restarted building libobjc2.
> 
> I get this failure during build:
> 
> Scanning dependencies of target CXXExceptions_legacy_optimised
> [  9%] Building C object 
> Test/CMakeFiles/CXXExceptions_legacy_optimised.dir/CXXException.m.o
> [ 10%] Building CXX object 
> Test/CMakeFiles/CXXExceptions_legacy_optimised.dir/CXXException.cc.o
> [ 10%] Linking C executable CXXExceptions_legacy_optimised
> ld: error: /home/multix/code/gnustep-cvs/libobjc2/Build/libobjc.so: undefined 
> reference to cxx_throw()
> ld: error: /home/multix/code/gnustep-cvs/libobjc2/Build/libobjc.so: undefined 
> reference to test_eh_personality
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> gmake[2]: *** 
> [Test/CMakeFiles/CXXExceptions_legacy_optimised.dir/build.make:123: 
> Test/CXXExceptions_legacy_optimised] Error 1
> gmake[1]: *** [CMakeFiles/Makefile2:558: 
> Test/CMakeFiles/CXXExceptions_legacy_optimised.dir/all] Error 2
> gmake: *** [Makefile:183: all] Error 2

This looks as if we’re still compiling in the code that calls the function that 
figures out the the C++ ABI at run time dynamically.  This is added here:

https://github.com/gnustep/libobjc2/blob/93fbf4d4bcf8b7bdb2dd2f11207a2e6eeba9c46c/CMakeLists.txt#L325

I believe it should be pulled out into a separate if block, because we disable 
ObjC++ here:

https://github.com/gnustep/libobjc2/blob/93fbf4d4bcf8b7bdb2dd2f11207a2e6eeba9c46c/CMakeLists.txt#L318

Can you try moving it out and raise a PR if it fixes the build for you?  We 
shouldn’t break the no-C++ case, at least, though it should be working on 
OpenBSD.

> 
> 
> (which, if memory serves me, was one of the tests failing on 6.7, but at 
> leaste everything compiled)
> 
> I am suspicious that I do not find the CXX_RUNTIME_LIB set by cmake.
> 
> While runing cmake, I saw this:
> 
> -- Testing C++ interop
> -- Testing /usr/lib/libsupc++.a as the C++ runtime library
> -- Testing /usr/lib/libc++abi.so.3.0 as the C++ runtime library
> -- Testing C++ standard library
> -- Using /usr/bin/cc
> -- No useable C++ runtime found
> 
> 
> why doesn't it like my runtime library?

The file that it tries to compile is in the cmake directory, can you try 
compiling it and see what happens?  The line that tries to compile it is here:

https://github.com/gnustep/libobjc2/blob/93fbf4d4bcf8b7bdb2dd2f11207a2e6eeba9c46c/CMakeLists.txt#L231

I don’t know why this would fail with either libc++abi.so.3.0 or with your C++ 
standard library.  Either should work and so I don’t know why this test would 
fail.

David

Re: GNUstep on Windows using Clang + MSVC ABI

[David Chisnall]

On 01/02/2021 18:24, Frederik Seiffert wrote:

Sorry everyone, looks like my earlier draft got sent out prematurely...


Am 29.01.2021 um 17:28 schrieb David Chisnall 
mailto:gnus...@theravensnest.org>>:


ld -r is pretty flaky everywhere.  LLD wasn't going to implement it at 
all and GNUstep was one of only two consumers so I think it's fair to 
say that it's pretty likely that it will continue to be intermittently 
broken by various linker versions.  I personally like the concept but 
it's probably better to not depend on it anywhere.


Yeah, hopefully this change will resolve these issues once and for all.

That being said, Richard raised one *potential* issue with this change 
on GitHub, which is that it increases the length of the command that the 
linker is being called with, as now all subproject object files are 
passed directly to the linker. Hopefully OS command line limits are 
large enough these days so that this won’t be an issue in practice, but 
I’d still encourage everyone to try building their projects with the 
"clang-msvc-support" branch of tools-make.


I'm curious about this.  GNUstep projects have fairly short linker lines 
in comparison with a bunch of C++ projects.  I had a quick look at the 
systems I have runningL


 - FreeBSD limits it to 256 KiB on processes with limited kernel 
virtual address space, 512 KiB elsewhere.
 - Linux limits it to 128KiB statically but can return a larger number 
via sysconf depending on the system.  For me, that is around 2MiB.

 - Windows limits it to 32 KiB, though cmd.exe only handles 8 KiB.

Even with the 8KiB limit, you'd need a few hundred files on the linker 
invocation for this to be a problem unless you're giving long absolute 
paths for everything.




Have you tried with the bash.exe in C:\Windows\System32?


I briefly tried building in WSL today, and the main difference to using 
an MSYS2 shell is that Autoconf will consider it cross-compiling. This 
means that some config checks will not be run (because Autoconf will 
think that it can’t run the binaries), and we would need to provide a 
cross.config file with pre-determined results of these config files 
instead (just like when cross-compiling e.g. for Android). This is 
obviously more fragile.


But this kind of illustrates what I consider the biggest challenge with 
this setup: the need to install and jump between different shells in 
order to build the whole system (i.e. CMD for libobjc2, libdispatch, and 
probably others; Bash/MSYS2 for GNUstep).


I’m not sure if there’s an elegant solution to this. My current line of 
thinking is to create a project like tools-android (tools-windows?) with 
Batch + Bash scripts to build all dependencies and GNUstep in their 
respective environments.


Oh, sorry, wrong bash.  The one I was thinking of is actually installed 
for me as c:\Program Files\Git\git-bash.exe.  It's installed by the git 
package and gives you a Windows-native bash environment.  If the 
configure scripts just depend on bash, that ought to be sufficient.





Is the -fuse-ld=lld line required?  You get LLD installed when you 
install clang, so it's not very important, but the runtime and its 
tests, at least, also work with LINK.EXE (though you may have to 
disable incremental linking if it's on by default).


I did:

I tried using the MS linker (link.exe), but while that seems to 
generally work fine linking ObjC files, it throws up at some 
configure tests (specifically when testing "whether objc really 
works"). Using LLD works though, so one must run Make configure with 
LDFLAGS="-fuse-ld=lld".


This is reproducible simply by compiling config/config.objc.m from 
libs-base:


$ clang -o conftest.exe config/config.objc.m -I/c/GNUstep/x64/include 
-L/c/GNUstep/x64/lib -fobjc-runtime=gnustep-2.0 -lobjc
LINK : conftest.exe not found or not built by the last incremental link; 
performing full link
conftest-b38f3b.o : warning LNK4078: multiple '.CRT' sections found with 
different attributes (40400040)
libcmt.lib(initializers.obj) : warning LNK4254: section '.CRT' 
(C040) merged into '.rdata' (4040) with different attributes >

$ ./conftest.exe
Segmentation fault


This file appears to depend on objc-common.g, which looks like a 
generated file.  It probably only needs it for the root-class attribute 
(which only raises a warning if it's omitted, so isn't the end of the 
world).  Aside from that, the file looks like a bunch of the tests that 
we have in the libobjc2 repo, which pass in CI, so I'm not sure what's 
going on there.  Can you add -### to the clang command line and see how 
it compares to the same thing for the libobjc2 tests?




$ lldb conftest.exe
(lldb) r
Process 165928 stopped
* thread #1, stop reason = Exception 0xc005 encountered at address 
0x7ffce04d1048: Access violation reading location 0x

     frame #0: 0x7ffce04d1048 objc.dll`objc_msgSend + 40
objc.dll`objc_msgSend:
->  

Re: GNUstep on Windows using Clang + MSVC ABI

[David Chisnall]

On 29/01/2021 16:03, Frederik Seiffert wrote:

Good news everyone: I’ve successfully built Base on Windows with Clang, 
libobjc2, and the MSVC ABI. This results in lib, DLL, and PDB files that should 
be usable in any Windows app without using the MinGW toolchain.


*Very* nice!



I’ve opened the following pull requests with the required changes:

- tools-make: https://github.com/gnustep/tools-make/pull/14
- libs-base: https://github.com/gnustep/libs-base/pull/168

A couple of notes:


- Linking subproject object files directly (instead of merging)

As David had suspected, merging the subproject object files turned out to be an 
issue: `ld -r` is not available on Windows, and using `ar cr` resulted in a 
subproject.o that didn’t contain all the symbols (I’m guessing because ar 
doesn't correctly handle PE/COFF files).

So I looked into how we could instead use the subproject object files directly 
when linking the project, and came up with this solution: instead of merging 
the object files into subproject.o, we simply write the list of object files to 
a subproject.txt file (in the same location), and read that to create 
SUBPROJECT_OBJ_FILES.

The change is pretty minimal and seems to work fine on all 
platforms/configurations in CI:
https://github.com/gnustep/tools-make/commit/434f957df0ad81b52a09e3f8c4a200734898b342

Given that this affects all platforms I’d appreciate everyone’s feedback on 
this, but given that issues with incremental linking with various setups has 
been talked about multiple times on the mailing list, I hope that this change 
will be an overall improvement.


ld -r is pretty flaky everywhere.  LLD wasn't going to implement it at 
all and GNUstep was one of only two consumers so I think it's fair to 
say that it's pretty likely that it will continue to be intermittently 
broken by various linker versions.  I personally like the concept but 
it's probably better to not depend on it anywhere.





- Building

Building with this setup requires using a standard (non-MinGW) Clang that e.g. comes with 
Visual Studio or is available as pre-built binary from the LLVM website, and requires 
passing a host to configure like --host=x86_64-pc-windows. Invoking `clang -v` should 
show a target like "x86_64-pc-windows-msvc". It *might* be that using a MinGW 
Clang works too when invoked with --target x86_64-pc-windows-msvc, but I haven’t tried 
that.


The easiest way of installing clang on Windows is via Chocolatey: just 
run `choco install llvm` once it's installed.  Choco is also the easiest 
way of installing cmake and Ninja for building the runtime.



The build is best done in an MSYS2 shell that does not have any additional 
*-devel packages installed that might get picked up by configure. Alternatively 
--disable-xxx flags can be used to prevent these dependencies to be picked up.


Have you tried with the bash.exe in C:\Windows\System32?



I’m currently building like this:

# tools-make
export CC=/C/LLVM/bin/clang
export CXX=/C/LLVM/bin/clang++
export OBJCXX=/C/LLVM/bin/clang++
./configure --host=x86_64-pc-windows --with-library-combo=ng-gnu-gnu 
--with-runtime-abi=gnustep-2.0 --prefix=/c/GNUstep/x64 LDFLAGS="-fuse-ld=lld"
make install


Is the -fuse-ld=lld line required?  You get LLD installed when you 
install clang, so it's not very important, but the runtime and its 
tests, at least, also work with LINK.EXE (though you may have to disable 
incremental linking if it's on by default).




# libs-base
. /c/GNUstep/x64/share/GNUstep/Makefiles/GNUstep.sh
./configure --host=x86_64-pc-windows --disable-iconv --disable-tls 
--disable-icu --disable-xml
make -j12 install


- Dependencies

While most dependencies should be available via NuGet, I have not been able to 
figure out yet how we might integrate NuGet packages into the build process. 
Downloading the packages results in individual folders per package with deeply 
nested folder structures containing the libraries for different architectures, 
debug/release targets, and Visual Studio versions.

For now I have manually copied the headers and libffi.lib import library 
(renamed to ffi.lib) from the libffi package, and the libffi.dll from the 
libffi.redist package.

For pthreads I have built http://www.sourceware.org/pthreads-win32/ from source by 
invoking "nmake clean VC" in a VS native tools command prompt, and manually 
copied the headers (pthread.h, sched.h, semaphore.h), pthreadVC2.lib (renamed to 
pthread.lib), and phtreadVC2.dll.


At some point it would be nice to lose this dependency.  I don't know 
how much the attitude to C++ in GNUstep has changed recently, but C++11 
now has a nice set of threading abstractions that provide everything 
that NSThread, NSLock and friends need.  If we use those instead of 
pthreads then we'd have something that worked on any platform with a 
C++11 implementation (Linux, Windows, Fuschia, Haiku, and so on).




I haven’t build with any other dependencies so far but that will be my next 

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Hi,


On 20/01/2021 20:30, Frederik Seiffert wrote:

There’s one more issue though: both [Test class] and [Test new] (with "Test" 
being defined in the DLL) only return null pointers in my testing. However subclassing 
the Test root class locally works fine and allows instantiating the subclass, as does a 
locally defined root class (same implementation as Test).

The following code (with "Sub" being a subclass of "Test"):

printf("%p %p\n", [Test class], [Test new]);
printf("%p %p\n", [Sub class], [Sub new]);

Prints:

 
7FF73EDB0080 0291D99247A8


Any idea? All other things I tried so far seemed to be working fine, though I’m 
sure this won’t be the last of my questions...


I think I misrememberd some details of the Windows ABI.  I wrote a 
little test compilation unit to look at it:


```obj-c
__attribute__((dllimport))
@interface Test
+ (id)new;
@end

@interface Sub : Test @end

@implementation Sub
+ (id)new
{
return (void*)1;
}
@end

int main(void)
{
[Test new];
[Sub new];
}
```

And compiled it with:

clang11  -S -fobjc-runtime=gnustep-2.0 -target x86_64-pc-windows-msvc 
-O1 -o - msg.m  -emit-llvm


This generates a global like this:

```llvm
@"$_OBJC_CLASS_Test" = external dllimport global i8*
```

This is a dllimport'd global, so one that can be referenced in the 
instruction stream and will have relocations applied.  It can't be 
referenced in a global and so there's an `.objc_early_init` function 
generated that initialises the isa pointer of the `Sub` class.


The message sends both directly load from the `_REF_` class pointer, 
which is declared like this:


```llvm
@"$_OBJC_REF_CLASS_Test" = external dllimport local_unnamed_addr global i8*
```

So this has a canonical home in the DLL that owns the class and every 
other message send must indirect via that.  Without the dllimport 
qualifier, clang generates:


```llvm
@"$_OBJC_CLASS_Test" = external global i8*
@"$_OBJC_REF_CLASS_Test" = external local_unnamed_addr global i8*
```

These are both local to the DLL or EXE that contains them and won't be 
correctly initialised.


It looks as if you are missing the dllimport attribute on the classes 
that you're referencing from another DLL.


In WinObjC, all of the classes are decorated with a macro that does the 
normal Windows dance of expanding to dllimport normally and dllexport 
when you are building the DLL that they come from.  These are missing 
from GNUstep, I'm not sure if you added them in your branch.


David

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 20/01/2021 15:54, Frederik Seiffert wrote:
I confirmed with dumpbin /exports that the .lib and DLL both contain 
these $_OBJC_REF_CLASS_ symbols, so I really don’t understand why it’s 
not found.


For reference, the $_OBJC_CLASS symbols are meant to be exported from a 
DLL, they are the canonical pointers to the classes.  The 
$_OBJC_REF_CLASS pointers are private to a library and are the pointer 
that code should use for references to a given class.  These are 
initialised to the corresponding $_OBJC_CLASS variables and the runtime 
can update them to something different if we change the structure of the 
class structure in a future ABI.


I don't know if anything in your build is confusing that?

David

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Hi,

On ELF platforms, there were some issues with the ld -r invocation that 
-base Additions did.  Can you try just adding the .m files from 
Additions directly to the -base project and see if that makes the 
problem go away?  I don't think that PE/COFF linkage really has any 
concept that maps to how we do the subproject thing in -make.


David

On 19/01/2021 14:53, Frederik Seiffert wrote:

Hi all,

Another update on the Clang MSVC ABI support front (which I’m trying to get to 
work in addition to MinGW + Clang)...

I’ve been making some good progress and was able to build Base as a DLL with 
this setup. The necessary build system changes are on the following branches 
(work in progress), which I will clean up and submit as PRs when this is 
working:
https://github.com/gnustep/tools-make/tree/clang-msvc-support
https://github.com/gnustep/libs-base/tree/clang-msvc-support


However it seems that the generated gnustep-base.lib does not contain symbols 
for the ObjC classes. I’m getting linker errors for each ObjC class I am 
referencing in a test program:


lld-link: error: undefined symbol: $_OBJC_REF_CLASS_NSArray

referenced by C:\Dev\tools-android\test.m:16
   C:\msys64\tmp\test-aef6cd.o:(WinMain)


lld-link: error: undefined symbol: __declspec(dllimport) 
$_OBJC_CLASS_NSConstantString

referenced by C:\msys64\tmp\test-aef6cd.o:(.objc_early_init)


Is there some flag I need to pass to lld-link to ensure these are exported? I 
currently have -dll and -export-all-symbols. I also tried adding 
__declspec(dllexport) to the @interface declaration of these classes to no 
avail.


Regarding the previous issue:


However, it fails checking for objc_sync_enter with the following linker errors 
– any ideas what these could be about?


I am guessing these somehow happen because referencing ObjC built-ins in a C 
file doesn’t work on Windows. I’m planning to skip these config checks when 
using this setup.


Thanks,
Frederik



Am 12.01.2021 um 21:47 schrieb Frederik Seiffert :

Hi all,

As a second option I’ve been working on trying to build using the MSVC ABI 
(i.e. without MinGW).

Using the latest Clang 11 from the LLVM website and Pthreads-win32, plus 
removing -lm from target.make, I was able to get quite a bit further running 
Base configure.

However, it fails checking for objc_sync_enter with the following linker errors 
– any ideas what these could be about?


configure:8038: checking for objc_sync_enter
configure:8038: /C/LLVM/bin/clang -o conftest.exe -g  -I/c/GNUstep/MSVC/x64/include 
-I/c/GNUstep/MSVC/x64/include -I/c/GNUstep/MSVC/x64/include 
-I/c/GNUstep/MSVC/x64/include  -x objective-c -fuse-ld=lld -L/c/GNUstep/MSVC/x64/lib 
-L/c/GNUstep/MSVC/x64/lib -L/c/GNUstep/MSVC/x64/lib -L/c/GNUstep/MSVC/x64/lib 
conftest.c  -lpthread -fuse-ld=lld -pthread -fexceptions -fobjc-runtime=gnustep-2.0 
-fblocks -L/home/Frederik -LSeiffert/GNUstep/Library/Libraries 
-L/c/GNUstep/MSVC/x64/lib -lobjc >&5
conftest.c:119:6: warning: incompatible redeclaration of library function 
'objc_sync_enter' [-Wincompatible-library-redeclaration]
char objc_sync_enter ();
 ^
conftest.c:119:6: note: 'objc_sync_enter' is a builtin with type 'int (id)'
1 warning generated.
lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$SEL

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$SEL

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$CLS

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$CLS

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$CLR

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$CLR

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$CAT

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$CAT

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$PCL

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$PCL

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$PCR

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__stop.objcrt$PCR

referenced by C:\tmp\conftest-78a937.o:(.objc_init)


lld-link: error: relocation against symbol in discarded section: 
__start_.objcrt$CAL

Re: GNUstep base fails - libobjc2 on NetBSD x86

[David Chisnall]

Hi Ricardo,

> On 3 Jan 2021, at 22:22, Riccardo Mottola  wrote:
> 
> /home/multix/code/libobjc2/Build/libobjc.so.4.6: text relocations
> /home/multix/code/libobjc2/Build/libobjc.so.4.6: Cannot write-enable text 
> segment: Permission denied


This is very odd.  I don’t suppose that, when you modify the CFLAGS you’re 
removing the -fPIC?  Aside from that, can you use objdump to print the 
relocations?  This is not a very helpful error message and without knowing 
where the text relocation is, I can’t suggest how to fix it.  I believe the 
only text relocations that we had in the assembly routines were fixed some 
years back.

David

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Hi all,

Sorry for the delayed response, I’ve now had time to do a little bit of digging 
to understand what’s needed here.

> On 22 Dec 2020, at 11:39, Frederik Seiffert  wrote:
> 
> Hi David and all,
> 
>> Am 02.12.2020 um 20:20 schrieb David Chisnall :
>> 
>> I am not sure if there is a good way of fixing this other than to use a MSVC 
>> target triple.  C++ EH interop almost certainly won't work if MinGW is 
>> targeting the Itanium ABI for C++ and I really don't want to support the 
>> horrible 'let's try to layer Itanium-style unwinding on top of SEH, what's 
>> the worst that can happen?' approach that MinGW uses.
> 
> I’ve been thinking about this some more, and it seems like there are two 
> (non-exclusive) ways forward with this:
> 
> 
> 1. Support building GNUstep with MSVC

To clarify:

This is proposing building GNUstep with the MSVC C++ ABI.  This is now well 
supported by clang (Chrome uses it on Windows, for example).  I had assumed 
that MinGW used it with the clang toolchains but apparently it doesn’t.  

>   *I think* this would mean that we have to enable building GNUstep with a 
> native Windows toolchain, i.e. without MinGW (unless there‘s a way to use 
> MSVC in a MinGW environment, but even then the dependencies would also need 
> to be built with MSVC). This poses a couple of questions / challenges:

Exactly, though that toolchain could be clang + lld, rather than any part of 
MSVC.

> 
>   - Dependencies: all dependencies would have to be built using MSVC as well. 
> I did a quick search and this seems to be possible e.g. for libxml2, libxslt, 
> libffi, and ICU, although some of the build instructions to do so seem pretty 
> involved (esp. for ICU). In contrast to MinGW where these dependencies can 
> simply be installed via Pacman, I don’t think there are pre-built packages of 
> these dependencies built with MSVC, so this adds a significant hurdle to 
> building GNUstep as a whole.

MSVC or Clang with the MSVC ABI.  If they are available as NuGet packages, then 
this is easy (ICU is, for example: https://www.nuget.org/packages/icu4c.v140/), 
just install it with NuGet and point the GNUstep build system at it.

>   - Build system / Autoconf: I don’t think we’d be able to use Autoconf and 
> Make, so we’d have to look into supporting e.g. CMake, which is probably a 
> significant undertaking.

I’m not 100% sure that this is the case.  Clang can target the MSVC ABI when 
invoked with either the gcc- or cl.exe-compatible driver, so you can still use 
clang.exe (not clang-cl.exe) to drive the build.  I have no idea how well 
autoconf in bash on Windows without MinGW though.

>   - Windows toolchain support in GNUstep sources: no idea what would be 
> needed here, but I assume that some code relying on MinGW toolchain 
> headers/libraries would need to be updated to use Windows APIs.

This may be non-trivial, though the Min in MinGW may help here: it largely just 
provides its own headers for Windows DLLs.  I think we’re using Windows APIs 
for a bunch of things already.  I believe that we use a pthreads compatibility 
layer on Windows, so these things would need to be modified to use the native 
Windows calls.  If no one cares about Windows XP anymore, we could probably get 
some nice improvements by using SlimRW locks for NSLock.


> 2. Support MinGW-style exception handling in libobjc2
> 
>   I don’t have any idea how involved this would be to support in libobjc2, 
> but using GNUstep in a MinGW environment is how it worked in the past on 
> Windows (with GCC), and so this would probably be what most users would 
> expect to work with Clang as well. (As a bonus it would be nice if libobjc2 
> could support being built from a MinGW shell, so that everything can be built 
> in the same environment.)

There are two bits here, supporting it in the runtime and supporting it in the 
compiler.  I believe that both are actually fairly easy.  It appears that MinGW 
comes with an adaptor that translates from SEH-style exceptions to MinGW-style 
exceptions, so we just need to build the Itanium version and a tiny wrapper 
function that calls _GCC_specific_handler and passes it the GNUstep runtime’s 
personality function.

The clang changes are probably of a similar size.

> I think both options are worth exploring and I’d appreciate anyone’s thoughts 
> on the above. Ultimately it seems that even if we get option 1 to work, 
> option 2 would be much more straightforward to users given the pre-built 
> dependencies provided by MSYS2 packages.

My guess is that Option 2 is about two hours of writing the code and then a day 
or two of figuring out why it doesn’t work.  Option 1 is probably not too much 
work for the majority of the code but is likely to be a huge amount of effort 
for the build system: the GNUstep build system r

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 02/12/2020 19:01, Frederik Seiffert wrote:


Am 01.12.2020 um 15:42 schrieb David Chisnall 
mailto:gnus...@theravensnest.org>>:


Please can you try the attached patch?


So the patch resolves the objc_begin_catch/objc_end_catch undefined 
symbols, but it doesn’t resolve __gnustep_objc_personality_v0 and adds 
some new linker errors ones:



lld-link: error: undefined symbol: __gnustep_objc_personality_v0
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(.xdata)
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(GCC_except_table2)
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(GCC_except_table4)

>>> referenced 121 more times


It looks as if the code to check which personality function is outside 
the runtime-specific code.  The attached diff should fix that.




lld-link: error: undefined symbol: vtable for 
__cxxabiv1::__class_type_info
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for NSObject)

>>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>>> referenced by obj/libgnustep-base.obj/GSTLS.m.o

lld-link: error: undefined symbol: vtable for 
__cxxabiv1::__si_class_type_info
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for 
NSException)

>>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>>> referenced by obj/libgnustep-base.obj/GSTLS.m.o

lld-link: error: undefined symbol: vtable for 
__cxxabiv1::__pointer_type_info
>>> referenced by 
obj/libgnustep-base.obj/GSHTTPAuthentication.m.o:(typeinfo for 
NSException*)

>>> referenced by obj/libgnustep-base.obj/GSTimSort.m.o
>>> referenced by obj/libgnustep-base.obj/GSTLS.m.o


This looks as if clang is still trying to use the Itanium C++ ABI.  When 
the Objective-C code is targeting windows, it now asks for RTTI from the 
CXXABI class, but somehow your target triple is asking for the Itanium 
ABI, so we emit Itanium ABI C++ RTTI things and they then fail to link 
because they refer to things that exist only on Itanium ABI C++ runtimes.


I am not sure if there is a good way of fixing this other than to use a 
MSVC target triple.  C++ EH interop almost certainly won't work if MinGW 
is targeting the Itanium ABI for C++ and I really don't want to support 
the horrible 'let's try to layer Itanium-style unwinding on top of SEH, 
what's the worst that can happen?' approach that MinGW uses.


David

index bdf70252b5ad..5957b5fff0d5 100644
--- a/clang/lib/CodeGen/CGException.cpp
+++ b/clang/lib/CodeGen/CGException.cpp
@@ -141,7 +141,9 @@ static const EHPersonality (const 
TargetInfo ,

   case ObjCRuntime::iOS:
   case ObjCRuntime::WatchOS:
 return EHPersonality::NeXT_ObjC;
-  case ObjCRuntime::GNUstep:
+  case ObjCRuntime::GNUstep:
+if (L.SEHExceptions)
+  return EHPersonality::MSVC_CxxFrameHandler3;
 if (L.ObjCRuntime.getVersion() >= VersionTuple(1, 7))
   return EHPersonality::GNUstep_ObjC;
 LLVM_FALLTHROUGH;
@@ -194,6 +196,8 @@ static const EHPersonality 
(const TargetInfo ,

 return getObjCPersonality(Target, L);

   case ObjCRuntime::GNUstep:
+if (L.SEHExceptions)
+  return EHPersonality::MSVC_CxxFrameHandler3;
 return EHPersonality::GNU_ObjCXX;

   // The GCC runtime's personality function inherently doesn't support

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 02/12/2020 16:24, David Wetzel wrote:
Wouldn’t it be better to have a windows build on the website to download 
as a binary?


There are Windows builds on the LLVM web site, you can install them via 
chocho on Windows.


David

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 02/12/2020 09:36, Frederik Seiffert wrote:

Am 01.12.2020 um 15:42 schrieb David Chisnall :

Please can you try the attached patch?


That was quick, thank you very much! I’m having some trouble building Clang via 
MINGW-packages (https://github.com/msys2/MINGW-packages/issues/7369), but I’ll 
let you know as soon as I get that to work.


You should be able to just do a Windows build with the VS command prompt 
and CMake.  I normally build clang with CMake + Ninja + either Visual 
Studio or an existing LLVM install on Windows.  There are no other 
dependencies.


David

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 01/12/2020 12:40, Frederik Seiffert wrote:

Am 30.11.2020 um 17:59 schrieb David Chisnall :

I think this is a clang bug.  I am probably guarding this on an MSVC target 
triple and not on SEH exceptions.  Please can you file a clang bug and assign 
it to me?



https://bugs.llvm.org/show_bug.cgi?id=48348

I hope I summarized this somewhat correctly. Happy to try to build Clang from 
source once there is a patch.

I know it might not be your say, but if there is any way to still get this into 
a Clang 11 point release that would be very much appreciated. If there’s 
anything I can do to help make that happen please just let me know.


Please can you try the attached patch?

Thanks,

David

diff --git a/clang/lib/CodeGen/CGObjCGNU.cpp 
b/clang/lib/CodeGen/CGObjCGNU.cpp

index 9825d7bca18c..102da37a99e2 100644
--- a/clang/lib/CodeGen/CGObjCGNU.cpp
+++ b/clang/lib/CodeGen/CGObjCGNU.cpp
@@ -2134,8 +2134,7 @@ CGObjCGNU::CGObjCGNU(CodeGenModule , unsigned 
runtimeABIVersion,

 ProtocolVersion(protocolClassVersion), ClassABIVersion(classABI) {

   msgSendMDKind = VMContext.getMDKindID("GNUObjCMessageSend");
-  usesSEHExceptions =
- 
cgm.getContext().getTargetInfo().getTriple().isWindowsMSVCEnvironment();

+  usesSEHExceptions = cgm.getLangOpts().SEHExceptions;

   CodeGenTypes  = CGM.getTypes();
   IntTy = cast(

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 30/11/2020 16:52, Frederik Seiffert wrote:

Some of these were also resolved by the PR (all the ones using OBJC_HOOK), so 
we’re just left with the exception handling ones (see above). Clang should be 
using SEH exception handling (not DWARF) according to verbose output, so it’s 
all pretty strange to me.


I think this is a clang bug.  I am probably guarding this on an MSVC 
target triple and not on SEH exceptions.  Please can you file a clang 
bug and assign it to me?


David

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Thanks,

It looks like you’ve already raised a PR to fix many of these.

> On 26 Nov 2020, at 12:18, Frederik Seiffert  wrote:
>>  Linking library libgnustep-base ...
>> lld-link: warning: obj/libgnustep-base.obj/GSLocale.m.o: locally defined 
>> symbol imported: $_OBJC_CLASS_NSConstantString (defined in 
>> obj/libgnustep-base.obj/GSString.m.o) [LNK4217]
>> ...
> 
> These warnings (a couple pages of them) are probably harmless but maybe 
> someone knows what they are about?

These are pretty-much unavoidable on Windows.  In C/C++, you typically use a 
macro to control dlimport / dlexport of various things depending on whether 
you’re building the library or building something using the library.  You can 
do this in Objective-C now, but it requires annotating all of the classes in 
-base, -gui.  I think both of these projects already provide a macro that tells 
you that you’re building the library itself, so maybe it’s not too painful.

> 
>> lld-link: error: undefined symbol: objc_skip_type_qualifiers
>> lld-link: error: undefined symbol: objc_skip_typespec
>> lld-link: error: undefined symbol: objc_alignof_type
>> lld-link: error: undefined symbol: objc_sizeof_type
>> lld-link: error: undefined symbol: objc_layout_structure
>> lld-link: error: undefined symbol: objc_layout_structure_next_member
>> lld-link: error: undefined symbol: objc_layout_structure_get_info
>> lld-link: error: undefined symbol: objc_get_type_qualifiers
>> lld-link: error: undefined symbol: objc_promoted_size
> 
> These were built as part of libobjc2 (encoding2.c), but they don’t seem to be 
> exported in the DLL. Is encoding.h missing some export statements?

Yup, these were missing their OBJC_PUBLIC things.  Actually, your PR put them 
on the definitions, which might not be right - they probably should go in the 
.h so that they become dlimport when not building libobjc2.

> 
>> lld-link: error: undefined symbol: __gnustep_objc_personality_v0
>> >>> referenced by obj/libgnustep-base.obj/GSICUString.m.o:(.xdata)
>> >>> referenced by obj/libgnustep-base.obj/NSRegularExpression.m.o:(.xdata)
>> >>> referenced by 
>> >>> obj/libgnustep-base.obj/NSRegularExpression.m.o:(GCC_except_table11)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) 
>> _objc_class_for_boxing_foreign_exception
>> >>> referenced by 
>> >>> obj/libgnustep-base.obj/CXXException.m.o:(_c_CXXException__load)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) _objc_weak_load
>> >>> referenced by obj/libgnustep-base.obj/NSObject.m.o:(_c_NSObject__load)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) _objc_load_callback
>> >>> referenced by obj/libgnustep-base.obj/objc-load.m.o:(GSPrivateLoadModule)
> 
> Not sure about these…

Neither am I.  These are used for DWARF exception handling, which we shouldn’t 
be doing on Windows.  It may be that we get them from using a MinGW or Cygwin 
target triple when building GNUstep?

David

Re: Crash on Linux+Clang (NSTimer)

[David Chisnall]

On 11/11/2020 23:26, Riccardo Mottola wrote:

It improves things definitely. Now gui apps start again.


Great!


Here the test-suite results:

76% tests passed, 44 tests failed out of 186

That's exactly the same number as before and the tests still fail, even 
if in "real world" things improved? That's mysterious.


I thought we tested 32-bit in CI, but it turns out we test only 32-bit 
Windows: for FreeBSD and Linux, we test only 64-bit x86.  For another 
project, we've set up some container thingies to use QEMU user mode for 
testing other architectures - I'll see if I can set that up for libobjc2 
so that we can test ARM as well.  32-bit builds ought to be easy anyway 
just by adding -m32 to various flags.




I tried starting Ink and more complex GWorkspace, Gorm, GNUMail, they 
all come up, load bundles, etc. So I think it is better than before and 
branched.


     Start 125: objc_msgSend
125/186 Test #125: objc_msgSend 
..Child aborted***Exception: 0.00 sec

     Start 126: objc_msgSend_optimised
126/186 Test #126: objc_msgSend_optimised 
Child aborted***Exception:   0.00 sec

     Start 127: objc_msgSend_legacy
127/186 Test #127: objc_msgSend_legacy 
...Child aborted***Exception:   0.00 sec

     Start 128: objc_msgSend_legacy_optimised
128/186 Test #128: objc_msgSend_legacy_optimised 
.Child aborted***Exception:   0.00 sec



How can I give you more details on these (and the other) failures? there 
are quite a lot.


Most of the tests run in a matrix of 4 configurations: debug / release 
builds, v1 and v2 ABIs, so it looks like 11 real failures.  I'll do a 
32-bit build locally and take a look.  It's a bit surprising


I don't know what differs from your setup, mine should be pretty 
"standard" in my intentions.


ccmake . shows I am using clang:

  CMAKE_CXX_COMPILER   /usr/lib/llvm/10/bin/clang++


This should work fine, I probably have some bugs.

David

Re: Crash on Linux+Clang (NSTimer)

[David Chisnall]

On 10/11/2020 23:33, Riccardo Mottola wrote:

Hello David,


thank you for the thorough analysis.





If this is the case, you'll be able to see by looking at the value of 
the %rsp register and the current instruction.  Please can you:


 - Use `show registers rsp` to let me know your current stack pointer 
value.

 - Use `disas` and show me the instruction that it points to



I don't have that registerm it is for x86-64, right? esp should be the 
equivalent IA-32, no?


Yes, sorry, I missed that this was 32-bit.



here my dump:

(gdb) info registers
eax    0xb7afa5e4  -1213225500
ecx    0xb7850510  -1216019184
edx    0x2 2
ebx    0xb7ad1000  -1213394944
esp    0xbfffeb84  0xbfffeb84
ebp    0x0 0x0
esi    0x834bde4   137674212
edi    0x833ef24   137621284
eip    0xb7850558  0xb7850558 <-[NSTimer 
initWithFireDate:interval:target:selector:userInfo:repeats:]+72>

eflags 0x210246    [ PF ZF IF RF ID ]
cs 0x73    115
ss 0x7b    123
ds 0x7b    123
es 0x7b    123
fs 0x0 0
gs 0x33    51


The SysV x86 ABI is a bit weird with stack alignment (for both 32- and 
64-bit), it mandates that the alignment is 16 bytes *before* a call 
instruction.  The all then subtracts one pointer from the stack.  This 
means that, on a 32-bit platform, on function entry (meaning on the 
first instruction - often the function entry breakpoint is after the 
prelude, which spills ebp and a few other things) $esp + 4 % 16 == 0




disas:

Dump of assembler code for function -[NSTimer 
initWithFireDate:interval:target:selector:userInfo:repeats:]:

    0xb7850510 <+0>:    push   %ebp
    0xb7850511 <+1>:    push   %ebx
    0xb7850512 <+2>:    push   %edi
    0xb7850513 <+3>:    push   %esi
    0xb7850514 <+4>:    sub    $0x1c,%esp
    0xb7850517 <+7>:    call   0xb785051c <-[NSTimer 
initWithFireDate:interval:target:selector:userInfo:repeats:]+12>

    0xb785051c <+12>:    pop    %ebx
    0xb785051d <+13>:    movsd  0x3c(%esp),%xmm0
    0xb7850523 <+19>:    mov    0x38(%esp),%ebp
    0xb7850527 <+23>:    mov    0x44(%esp),%edi
    0xb785052b <+27>:    mov    0x30(%esp),%esi
    0xb785052f <+31>:    xorpd  %xmm1,%xmm1
    0xb7850533 <+35>:    add    $0x280ae4,%ebx
    0xb7850539 <+41>:    movsd  -0x10d648(%ebx),%xmm3
    0xb7850541 <+49>:    movapd %xmm0,%xmm2
    0xb7850545 <+53>:    test   %ebp,%ebp
    0xb7850547 <+55>:    cmpnlesd %xmm1,%xmm2
    0xb785054c <+60>:    andpd  %xmm2,%xmm0
    0xb7850550 <+64>:    andnpd %xmm3,%xmm2
    0xb7850554 <+68>:    orpd   %xmm0,%xmm2


Unfortunately, this is not the dump at the point where it crashed.  The 
faulting instruction is the one immediately after this.  If you run 
disas at the point where it breaks, you will get a => indicator next to 
the faulting instruction.







For extra confirmation, put an breakpoint on the first instruction of 
`NSRunLoop`'s  `+initialize` and let me know what the value of %rsp is 
on function entry?



That would be breaking:

Breakpoint 1, +[NSRunLoop initialize] (
     self=0xb7af2944 <._OBJC_CLASS_NSRunLoop>, _cmd=0x8085db0)
     at NSRunLoop.m:746
746      if (self == [NSRunLoop class])

(gdb) info registers esp
esp    0xbfffec44  0xbfffec44


You need to put it on the first instruction.  The gdb syntax for this is 
`b *0x{whatever the address of the function is`.






Looking at the code, I think we are spilling 24 8-byte words to the 
stack, but the weirdness related to the x86 call instruction means 
that we will be doing the wrong thing for the ABI.



Before any fix, libobjc2  test suite:

76% tests passed, 44 tests failed out of 186

Notably:

     125 - objc_msgSend (Child aborted)
     126 - objc_msgSend_optimised (Child aborted)
     127 - objc_msgSend_legacy (Child aborted)
     128 - objc_msgSend_legacy_optimised (Child aborted)


That's interesting.  We run those tests in CI, I wonder what is 
different on your platform.






If you want to try a fix, I believe changing the 0x98 to 0xa0 on these 
two lines should work:


https://github.com/gnustep/libobjc2/blob/41808111aa0a58708daf66b2322940d4353e37d8/objc_msgSend.x86-64.S#L216 



https://github.com/gnustep/libobjc2/blob/41808111aa0a58708daf66b2322940d4353e37d8/objc_msgSend.x86-64.S#L257 



I believe doing that should cause the objc_msgSend test in the 
runtime's test suite to fail, but then changing the 0xD8 to 0xE0 on 
this line should fix it:


https://github.com/gnustep/libobjc2/blob/41808111aa0a58708daf66b2322940d4353e37d8/objc_msgSend.x86-64.S#L241 





If your theory about alignment still applies, maybe you can hint me the 
32bit version of it?


The 32bit method in slowLookUp is much shorter :)


Yup, in the 32-bit ABI all arguments are stored 

Re: Crash on Linux+Clang (NSTimer)

[David Chisnall]

Hi Riccardo,

Nothing there looks obviously wrong, but the fact that you're getting a 
SEGV on an line that isn't explicitly accessing memory is interesting, 
as is the fact that this is in a `+initialize` method.


I wonder if the code in `objc_msgSend` is leaving the stack incorrectly 
aligned?  I encountered a similar problem with some assembly trampolines 
in another project recently, where everything was fine 99% of the time, 
but in a few cases the compiler was using SSE instructions on the stack 
and was crashing because the stack pointer was only 8-byte aligned and 
not the ABI-mandated 16-byte aligned.


If this is the case, you'll be able to see by looking at the value of 
the %rsp register and the current instruction.  Please can you:


 - Use `show registers rsp` to let me know your current stack pointer 
value.

 - Use `disas` and show me the instruction that it points to

For extra confirmation, put an breakpoint on the first instruction of 
`NSRunLoop`'s  `+initialize` and let me know what the value of %rsp is 
on function entry?


Looking at the code, I think we are spilling 24 8-byte words to the 
stack, but the weirdness related to the x86 call instruction means that 
we will be doing the wrong thing for the ABI.


If you want to try a fix, I believe changing the 0x98 to 0xa0 on these 
two lines should work:


https://github.com/gnustep/libobjc2/blob/41808111aa0a58708daf66b2322940d4353e37d8/objc_msgSend.x86-64.S#L216

https://github.com/gnustep/libobjc2/blob/41808111aa0a58708daf66b2322940d4353e37d8/objc_msgSend.x86-64.S#L257

I believe doing that should cause the objc_msgSend test in the runtime's 
test suite to fail, but then changing the 0xD8 to 0xE0 on this line 
should fix it:


https://github.com/gnustep/libobjc2/blob/41808111aa0a58708daf66b2322940d4353e37d8/objc_msgSend.x86-64.S#L241

David

On 08/11/2020 22:44, Riccardo Mottola wrote:

HI,


I just recompiled all GNUstep on Linux-x86/clang+libobjc2

libobjc2 is linked with the gold linker, clang is 10.0 - so every pretty 
new!


Any GUI apps crashes (things pliek plparse, plmerge do run)


Starting program: /Local/Tools/Ink
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0xb7850558 in -[NSTimer 
initWithFireDate:interval:target:selector:userInfo:repeats:] 
(self=0x834c2f4,
     _cmd=0xb7b2ce94 
<.objc_selector_initWithFireDate:interval:target:selector:userInfo:repeats:_360:48d1220:2428C32>, 

     fd=0x0, ti=30, object=0x833f434, selector=0x0, info=0x0, f=1 
'\001') at NSTimer.m:119

119      if (ti <= 0.0)


#0  0xb7850558 in -[NSTimer 
initWithFireDate:interval:target:selector:userInfo:repeats:] 
(self=0x834c2f4,
     _cmd=0xb7b2ce94 
<.objc_selector_initWithFireDate:interval:target:selector:us#17 
0xb7c022c6 in NSApplicationMain (argc=, argv=out>) at Functions.m:87
#18 0x08049200 in main (argc=, argv=, 
env=) at main.m:30

erInfo:repeats:_360:48d1220:2428C32>,
     fd=0x0, ti=30, object=0x833f434, selector=0x0, info=0x0, f=1 
'\001') at NSTimer.m:119
#1  0xb7822d56 in +[NSRunLoop _runLoopForThread:] (self=, 
_cmd=, aThread=)

     at NSRunLoop.m:785
#2  0xb7822db5 in +[NSRunLoop currentRunLoop] (self=, 
_cmd=) at NSRunLoop.m:812
#3  0xb7822b36 in +[NSRunLoop initialize] (self=, 
_cmd=) at NSRunLoop.m:748
#4  0xb75f0fcd in objc_send_initialize () from 
/System/Library/Libraries/libobjc.so.4.6
#5  0xb75fca25 in slowMsgLookup () from 
/System/Library/Libraries/libobjc.so.4.6
#6  0xb7602951 in objc_msgSend () from 
/System/Library/Libraries/libobjc.so.4.6
#7  0xb45d12ba in -[XGServer(EventOps) setupRunLoopInputSourcesForMode:] 
(self=, _cmd=,

     mode=) at XGServerEvent.m:231
#8  0xb45d02e1 in -[XGServer initWithAttributes:] (self=, 
_cmd=, info=)
     at XGServer.m:493#17 0xb7c022c6 in NSApplicationMain 
(argc=, argv=) at Functions.m:87
#18 0x08049200 in main (argc=, argv=, 
env=) at main.m:30


#9  0xb7d84e02 in +[GSDisplayServer serverWithAttributes:] 
(self=, _cmd=,

     attributes=) at GSDisplayServer.m:181
#10 0xb7c19ac1 in -[NSApplication _init] (self=, 
_cmd=) at NSApplication.m:892
#11 0xb77ecada in -[NSObject performSelector:withObject:] 
(self=, _cmd=,
     aSelector=, anObje$ ./configure --prefix=/ 
--with-layout=gnustep --with-library-combo=ng-gnu-gnu ct=out>) at NSObject.m:2027
#12 0xb784fe4d in -[NSObject(NSThreadPerformAdditions) 
performSelector:onThread:withObject:waitUntilDone:modes:] (
     self=, _cmd=, aSelector=out>, aThread=0x8157bb4, anObject=,

     aFlag=, anArray=) at NSThread.m:2168
#13 0xb784fa1c in -[NSObject(NSThreadPerformAdditions) 
performSelectorOnMainThread:withObject:waitUntilDone:modes:] (
     self=, _cmd=, aSelector=out>, anObject=, aFlag=,

     anArray=) at NSThread.m:2123
#14 0xb784fb6f in -[NSObject(NSThreadPerformAdditions) 
performSelectorOnMainThread:withObject:waitUntilDone:] (
     self=, _cmd=, aSelector=out>, anObject=, aFlag=)$ ./configure 
--prefix=/ 

Re: FreeBSD 12.2 cannot build back

[David Chisnall]

On 30/10/2020 18:31, Riccardo Mottola wrote:

I wonder if this is a gnustep-make issue or a project issue?


My guess is a -make issue.  I suspect a newer LLD is more aggressive 
about rejecting incompatible options than older linkers.


Where are -r and -rdynamic coming from? I found nothing therelike in 
gsc's subproject itself.


-r is from the subproject makefile.  Subprojects are linked as a .o file 
that is then subsequently linked into the final binary, which requires -r.


I believe -rdynamic is added globally because it's necessary for dladdr 
to give useful outputs on most ELF platforms, which is essential for 
pretty back traces.  We probably need to explicitly remove it from 
LDFLAGS in the subproject things in -make (it's only meaningful when 
producing a fully linked output).


David

Re: openbsd macppc clang broken va_args(_, id)

[David Chisnall]

Hi,

The PowerPC back end in clang is probably not well tested with Objective-C.  If 
you have a reduced test case (i.e. something that *doesn’t* include any 
headers), it would be a good idea to file a bug against clang.

The logic for setting up variadic call frames and handling va_arg are 
completely disconnected in clang and so it’s entirely possible that id is 
handled differently in the PowerPC back end.  It’s mostly maintained by IBM 
folks these days and I don’t think Objective-C is something that they’re going 
to be testing regularly.

David

> On 10 Oct 2020, at 22:46, Anthony Richardby  wrote:
> 
> Hi,
> I've been trying to get GNUstep up and running on my powerpc setup for
> a little while, and
> I figure this is the best place to ask for advice, or if anybody knows
> some trick I'm not aware of!
> 
> The problem:
> Using 'va_arg()' with type 'id' just doesn't work, you certainly don't
> get back the arguments to
> the function, at least. For example, consider the following program:
> 
> #include 
> #include 
> 
> id test(id first, ...) {
>va_list ap;
>id second, third;
> 
>va_start(ap, first);
>second = va_arg(ap, id);
>third = va_arg(ap, id);
>return third;
> }
> 
> 
> int main(int argc, char **argv) {
>NSString *str1 = @"test1";
>NSString *str2 = @"test2";
>NSString *str3 = @"test3";
> 
>id res = test(str3, str2, str3);
>printf("%x\n", res);
>if (str3 == res) {
>printf("works\n");
>} else {
>printf("broken\n");
>}
>return 0;
> }
> 
> When run, this prints out:
> 
> netty$ ./obj/Hello
> 0
> broken
> 
> And actually, debugging this shows that va_arg is returning the same
> data each for 'second'
> and 'third'.
> 
> Breakpoint 1, test (first=0x382b48f8) at main.m:11
> 11  return third;
> Current language:  auto; currently minimal
> (gdb) p first
> $1 = 0x382b48f8
> (gdb) p second
> $2 = 0x3fe0
> (gdb) p third
> $3 = 0x0
> (gdb)
> 
> 'second' and 'third' are always 0x3fe0, and 0x0 on every single
> run.
> 
> Replacing 'va_arg(ap, id)' with 'va_arg(ap, void*)' makes the program
> run as exected.
> Outputing:
> netty$ ./obj/Hello
> 1e5a4910
> works
> 
> For the moment, I've got everything working just by replacing all
> occurrances of 'id' when used with
> va_arg with 'void*'. And everything seems to work just fine. The funny
> thing is, this seems to be
> specific to 'id' - is it given special treatment somehow?
> 
> I'm running OpenBSD 6.7, building from a slightly modified ports tree
> (it's disabled on macppc
> by default) CC/CXX is set to base clang.
> 
> Anyone got ideas what's going on here?
> 
> Cheers,
> Anthony.
> 
> 
> 
> 

Re: libobjc2-clang

[David Chisnall]

Thanks!

> On 18 Jun 2020, at 12:52, Riccardo Mottola  wrote:
> 
> you guessed correctly and the protocol is also a very common one, NSCopying

So, part of the question is whether this is the first time we’re seeing this or 
not.  Can you stick a watchpoint on the isa pointer and restart it, see if it’s 
modified before here?

> (gdb) p *protocols
> $4 = {next = 0x0, count = 2, list = 0x7b8aa32ea1c0 }
> 
> (gdb) p i
> $1 = 0
> (gdb) p aProto
> $2 = (struct objc_protocol *) 0x7b8aa39138b8 <._OBJC_PROTOCOL_NSCopying>
> 
> 
> version is small:
> (gdb) p version
> $3 = 0

That’s very odd.  Here’s the definition of the enum:

https://github.com/gnustep/libobjc2/blob/369c84db35a6a1e94f8a4689a695fabdac056166/protocol.h#L26

The isa pointer for each protocol is initially set to one of those enum values 
(2, 3, or 4) by the compiler and is then set to a proper Objective-C class.  It 
should never end up 0.  It’s possible that something has corrupted memory or 
that we’ve just read the low 32 bits this has been set to a 64-bit address that 
happens to have nothing in the low 32 bits, but it seems quite unlikely.


>> Can you also confirm whether you’ve built with OLDABI_COMPAT enabled?  If 
>> you didn’t, then you’ll see this message if you try to load any code that 
>> isn’t compiled with the v2 ABI.
> 
> I confirm OLDABI_COMPAT is on. I did not touch it. LEGACY_COMPAT is off.
> 
> I only changed the linker option and then the build type.
> 
> Further question: this is a from-scratch install, all compiled with the same 
> version of clang, can I assume that all libraryes have the same ABI or not? 
> maybe there is a makefile issue somewhere?

Should be.  You can see if __objc_exec_class is called - that’s the entry point 
used by old ABI code.

David

Re: libobjc2-clang

[David Chisnall]

Wow, I ignored email for a week and there are 50 unread emails in my GNUstep 
folder!  Great to see some renewed interest and activity in the project!

> On 17 Jun 2020, at 12:28, Riccardo Mottola  wrote:
> 
> Hi,
> 
> Wolfgang Lux wrote:
>>> Perhaps libobjc? how can I compile libobic2 in debug? I think I need to 
>>> activate  CMAKE_ASM_FLAGS_DEBUG somehow
>> No. But you want to reconfigure libobjc2 with 
>> CMAKE_BUILD_TYPE=RelWithDebInfo (or, if you absolutely insist on turning off 
>> optimization, CMAKE_BUILD_TYPE=Debug).
> 
> thank you. I used "Debug" to be most extreme (and also to exclude issues with 
> optimizations, which never hurts).

Debug doesn’t make actually much of a difference to overall performance.  The 
most performance critical bits are hand-coded assembly.

> It still crashes and so:
> 
> 0x753c801678aa in _lwp_kill () from /usr/lib/libc.so.12
> (gdb) bt
> #0  0x753c801678aa in _lwp_kill () from /usr/lib/libc.so.12
> #1  0x753c8016715a in abort () from /usr/lib/libc.so.12
> #2  0x753c80a18d56 in init_protocols (protocols=0x753c816c91b0 
> )
> at /home/multix/code/gnustep-vcs/libobjc2/protocol.c:225
> #3  0x753c80a18b0d in objc_init_protocols (protocols=0x753c816c91b0 
> )
> at /home/multix/code/gnustep-vcs/libobjc2/protocol.c:258
> #4  0x753c80a12647 in objc_load_class (class=0x753c816c91d0 
> <._OBJC_CLASS_NSAffineTransform>)
> at /home/multix/code/gnustep-vcs/libobjc2/class_table.c:465
> #5  0x753c80a18235 in __objc_load (init=0x753c816ba9a0 )
> at /home/multix/code/gnustep-vcs/libobjc2/loader.c:268
> #6  0x753c812baced in objcv2_load_function () from 
> /System/Library/Libraries/libgnustep-base.so.1.27.0
> #7  0x753c812b9ab4 in ?? () from 
> /System/Library/Libraries/libgnustep-base.so.1.27.0
> #8  0x753c81cf7c00 in ?? ()
> #9  0x753c812b6749 in _init () from 
> /System/Library/Libraries/libgnustep-base.so.1.27.0
> #10 0x in ?? ()
> 
> how can I print out this?
> (gdb) p protocols
> $4 = (struct objc_protocol_list *) 0x753c816c91b0 
> 
> just to know which "list" and what should be loaded, I suppose there is an 
> error here.

This is the protocol list that is currently being initialised.  It would be 
interesting to see what `i` is (I guess 0), because they tells us if we’re 
failing on the first protocol in a class or a subsequent one.  Then look at 
`version`, which should be a protocol version number.  If it isn’t a small 
value (<16), look at `aProto->isa`.

Can you also confirm whether you’ve built with OLDABI_COMPAT enabled?  If you 
didn’t, then you’ll see this message if you try to load any code that isn’t 
compiled with the v2 ABI.

David

Re: libobjc2-clang

[David Chisnall]

Hi,

From the back trace, this looks as if it's the v2 ABI.  The assert 
that's firing is here:


https://github.com/gnustep/libobjc2/blob/ed8eec6c6aa82b049fc8292d0c247b8cd6c2fddc/protocol.c#L224

So it's finding an isa pointer for a protocol that is neither the one of 
the known protocol classes and not a known version number.  So the 
question is... what is it?  Can you walk up the stack to that point and see?


David

On 10/06/2020 18:15, Riccardo Mottola wrote:

Hi,

I am testing a bit libobjc2 + clang on NetBSD/amd64
As we know, the full libobjc2 testsuite passes and most apps appear to 
work.


There are some oddities though, like this:

Unknown protocol version[1]   Abort trap (core dumped) Vespucci

as soon as I launch it, it crashes.

Starting program: /Local/Tools/Vespucci
Unknown protocol version
Program received signal SIGABRT, Aborted.
0x7a34713678aa in _lwp_kill () from /usr/lib/libc.so.12
(gdb) bt
#0  0x7a34713678aa in _lwp_kill () from /usr/lib/libc.so.12
#1  0x7a347136715a in abort () from /usr/lib/libc.so.12
#2  0x7a3471c18d56 in init_protocols () from 
/System/Library/Libraries/libobjc.so.4.6

#3  0x7a3471c18b0d in objc_init_protocols ()
    from /System/Library/Libraries/libobjc.so.4.6
#4  0x7a3471c12647 in objc_load_class () from 
/System/Library/Libraries/libobjc.so.4.6
#5  0x7a3471c18235 in __objc_load () from 
/System/Library/Libraries/libobjc.so.4.6
#6  0x7a34725730a4 in ?? () from 
/System/Library/Libraries/libgnustep-base.so.1.27.0

#7  0x7a3472ed9c00 in ?? ()
#8  0x7a347256ff69 in _init () from 
/System/Library/Libraries/libgnustep-base.so.1.27.0

#9  0x in ?? ()


Ideas?

Riccardo

Re: building libobjc2 fPIC issue and ccmake . effectiveness

[David Chisnall]

On 30 May 2020, at 22:51, Riccardo Mottola  wrote:
> 
> Hi David,
> 
> thanks for the help. Got a little further, but not enough.
> 
> On 5/29/20 2:00 PM, David Chisnall wrote:
>> 
>> We shouldn't be linking libsupc++.a into libobjc.so.  It sounds as if NetBSD 
>> ships a separate C++ runtime library for static linking, but not for dynamic 
>> linking.  You can work around this by explicitly setting libstdc++ as your 
>> C++ runtime library in the libobjc2 cmake config.
>> 
>> The correct fix it so tweak the C++ runtime library check in CMake so that 
>> it looks only for dynamic 
> 
> 
> I have libstdc++.so and libstdc++.a available, and libsupc++.a
> 
> so I use ccmake. and set
> 
> CXX_RUNTIME_LIB to /usr/lib/libstdc++.so
> 
> then I run (c)onfigure and (g)enerate - at that point libobjc2 fully built 
> and installed.

Great!  I am a bit confused as to why it’s finding the .a, because that should 
be looking for only libraries that end with ${CMAKE_SHARED_LIBRARY_SUFFIX}, 
which should be .so on ELF platforms.  We might need an extra check here.

> 
> I was able to reconfigure make, install base with success, but gui fails.
> 
> 
> Well, even something as easy as plparse coredumps.
> 
> crossbar$ plparse
> [1]   Segmentation fault (core dumped) plparse
> 
> 
> #0  0x7ed0cbf45c5d in __vfprintf_unlocked_l () from /usr/lib/libc.so.12
> #1  0x7ed0cbf43c1d in vsnprintf_l () from /usr/lib/libc.so.12
> #2  0x7ed0cbf43d11 in snprintf () from /usr/lib/libc.so.12
> #3  0x7ed0cd254244 in -[NSMethodSignature _initWithObjCTypes:] (
> self=, _cmd=, t=)
> at NSMethodSignature.m:539
> #4  0x7ed0cd254391 in +[NSMethodSignature signatureWithObjCTypes:] (
> self=, _cmd=, t=0x7ed0cd40bc4c "%d")
> at NSMethodSignature.m:559
> #5  0x7ed0cd2ff2da in gs_objc_msg_forward2 (
> receiver=0x7ed0cd6f9430 <._OBJC_CLASS_NSString>,
> sel=0x7ed0cd73e788 
> <.objc_selector_stringWithFormat:arguments:_
32
0:8
16[1{__va_list_tag=II^v^v}]24>)
>  at GSFFIInvocation.m:140
> #6  0x7ed0ccc20639 in slowMsgLookup ()
>from /System/Library/Libraries/libobjc.so.4.6
> #7  0x7ed0ccc25ef0 in objc_msgSend_fpret ()
>from /System/Library/Libraries/libobjc.so.4.6
> #8  0x7ed0cd21f696 in +[NSException raise:format:arguments:] (
> self=0x7ed0cd6d1d58 <._OBJC_CLASS_NSException>, _cmd=,
> name=0x7ed0cd7271a8 <.objc_str_NSInvalidArgumentException>,
> format=0x7ed0cd40bc4c, argList=0x7f7fffb6aa48) at NSException.m:1463
> #9  0x7ed0cd21f660 in +[NSException raise:format:] (self=0x7f7fffb6a7b0,
> _cmd=, name=0x7ed0cd40bc4c, format=0x7f7fffb6aa48)
> at NSException.m:1450
> #10 0x7ed0cd262036 in -[NSObject doesNotRecognizeSelector:] (
> self=, _cmd=,
> aSelector=0x7ed0cd73e788 
> <.objc_selector_stringWithFormat:arguments:_
32
0:8
16[1{__va_list_tag=II^v^v}]24>)
>  at NSObject.m:1738
> #11 0x7ed0cd30020e in GSFFIInvocationCallback (cif=0x7ed0c6151820,
> retp=0x7f7fffb6b310, args=0x7f7fffb6b170, user=0x7ed0c6157f88)
> at GSFFIInvocation.m:606
> #12 0x7ed0ca20299c in ffi_closure_unix64_inner ()
>from /usr/pkg/lib/libffi.so.7
> #13 0x7ed0ca202d10 in ffi_closure_unix64 () from /usr/pkg/lib/libffi.so.7
> #14 0x7ed0cd21f696 in +[NSException raise:format:arguments:] (
> self=0x7ed0cd6d1d58 <._OBJC_CLASS_NSException>, _cmd=,
> name=0x7ed0cd7271a8 <.objc_str_NSInvalidArgumentException>,
> format=0x7ed0cd40bc4c, argList=0x7f7fffb6aa48) at NSException.m:1463
> #15 0x7ed0cd21f660 in +[NSException raise:format:] (self=0x7f7fffb6a7b0,
> _cmd=, name=0x7ed0cd40bc4c, format=0x7f7fffb6aa48)
> at NSException.m:1450
> #16 0x7ed0cd262036 in -[NSObject doesNotRecognizeSelector:] (
> self=, _cmd=,
> aSelector=0x7ed0cd73e788 
> <.objc_selector_stringWithFormat:arguments:_
32
0:8
16[1{__va_list_tag=II^v^v}]24>)
>  at NSObject.m:1738
> #17 0x7ed0cd30020e in GSFFIInvocationCallback (cif=0x7ed0c6151780,
> retp=0x7f7fffb6b690, args=0x7f7fffb6b4f0, user=0x7ed0c6157f48)
> at GSFFIInvocation.m:606
> #18 0x7ed0ca20299c in ffi_closure_unix64_inner ()
>from /usr/pkg/lib/libffi.so.7
> #19 0x7ed0ca202d10 in ffi_closure_unix64 () from /usr/pkg/lib/libffi.so.7
> #20 0x7ed0cd21f696 in +[NSException raise:format:arguments:] (
> self=0x7ed0cd6d1d58 <._OBJC_CLASS_NSException>, _cmd=,
> name=0x7ed0cd7271a8 <.objc_str_NSInvalidArgumentException>,
> format=0x7ed0cd40bc4c, argList=0x7f7fffb6aa48) at NSException.m:1463
> #21 0x7ed0cd21f660 in +[NSException raise:format:] (self=0x7f7fffb6a7b0,
> _cmd=, name=0x7ed0cd40bc4c, format=

Re: building libobjc2 fPIC issue and ccmake . effectiveness

[David Chisnall]

Hi,

On 29/05/2020 13:24, Riccardo Mottola wrote:

Hi!

I am trying to build libobjc2 on NetBSD

Linking fails (standard system linker)

[  0%] Linking C shared library libobjc.so
/usr/bin/ld: /usr/lib/libsupc++.a(eh_globals.o): relocation


We shouldn't be linking libsupc++.a into libobjc.so.  It sounds as if 
NetBSD ships a separate C++ runtime library for static linking, but not 
for dynamic linking.  You can work around this by explicitly setting 
libstdc++ as your C++ runtime library in the libobjc2 cmake config.


The correct fix it so tweak the C++ runtime library check in CMake so 
that it looks only for dynamic libraries.


David

Re: 24-bit retain count

[David Chisnall]

On 21/05/2020 15:37, Larry Campbell wrote:

Currently gnustep-base raises an exception if the retain count exceeds 24 bits. 
There's a comment there:

   /* I've seen comments saying that some platforms only support up to
* 24 bits in atomic locking, so raise an exception if we try to
* go beyond 0xfe.
*/

Is this really true? On what platforms? 24 bits is really not a very big 
number. (It is causing me pain right now.)


The runtime currently uses a pointer-sized integer for the refcount, but 
steals the top bit as a flag to indicate whether the object has ever had 
weak references taken.  This means that the limit on 32-bit platforms is 
2^31 references.  When this saturates, we never decrement it, so the 
object leaks.  Given that you can't fit 2^31 4-byte pointers in a 32-bit 
address space, this won't affect any correct code.


On 64-bit platforms, iOS (and macOS?) embeds a small refcount in the isa 
pointer.  I'd quite like to do this at some point.  When this saturates, 
the object starts hitting slow paths because its refcount is now stored 
in a look-aside table.


For your particular use case, I have a few observations:

1. Don't do object pooling for small strings on 64-bit platforms. 
Strings that are 8 or fewer 7-bit characters are stored embedded in the 
pointer.  Copying these is cheaper than adding an indirection layer.  A 
*lot* of XML attribute names and values will fit in this size.


2. If you are doing interning you can avoid a lot of refcount 
manipulation by storing their ID in the pool, rather than the pointer. 
You can probably get away with 32-bit IDs, rather than 64-bit pointers. 
This will also reduce your memory consumption.


David

Re: CMake 3.16

[David Chisnall]

On 16/05/2020 03:52, Ivan Vučica wrote:

Current Debian stable, from July 2019, has 3.13. Debian testing,
eventually becoming stable, has a 3.16 version in it.

Therefore, I can easily use 3.16 myself.

I know you're asking about/our/  /development/  machines, but for
end-users, I'd say most Ubuntu users will still be on 18.04 LTS, some
might be on 16.04 LTS (given 5yr support didn't run out yet). It would
probably be nice to wait at least a bit before nuking support for
18.04 and its derivatives. And I suppose CentOS that Richard mentioned
is also important to keep in mind?

If you want to move to it sooner rather than later, how about an
alternative deprecated CMakeLists.txt for older systems, one which
gets phased out in ~1.5-2y or so?


This isn't urgent.  It will make the build system more maintainable, but 
the build system doesn't change very much so it isn't a huge burden to 
maintain the current version for a while.  If 1.5-2 years gives everyone 
enough time to update, then I'll look at this again then.


David

CMake 3.16

[David Chisnall]

Hi all,

At some point, I'd like to move libobjc2 to requiring at least CMake 
3.16.  3.15 gained support for driving the GCC-flavoured clang on 
Windows with the Visual Studio ABI (older versions have to use clang-cl, 
which takes Visual Studio-compatible arguments).  3.16 gained native 
support for building Objective-C[++].


Both of these changes will reduce the complexity of the libobjc2 build 
system.  Currently, I have 3.17.2 on Windows and FreeBSD, installed from 
choco on Windows and the default package system on FreeBSD, but I am 
aware that other platforms are less good at updating developer tools.


What is the most recent cmake that is easy to install on your GNUstep 
development systems?  I'd like to get an idea of when moving to 
depending on 3.16 (released last November) will be viable for most people.


David

Re: libobjc2 on FreeBSD 12.1

[David Chisnall]

On 29/04/2020 22:00, Johannes Brakensiek wrote:

Hi Dave,

On 29 Apr 2020, at 22:18, David Wetzel wrote:

/usr/home/dave/libobjc2/arc.mm:6:10: fatal error:
'third_party/robin-map/include/tsl/robin_map.h' file not found
#include "third_party/robin-map/include/tsl/robin_map.h"

you probably missed to get the git submodules:

|git submodule init git submodule sync git submodule update |


Alternatively, just clone with:

git clone https://github.com/gnustep/libobjc2 --recurse

It' a good idea to internalise that as your default clone command or you 
will have exactly the same issue with any git project that uses submodules.


David

Re: wasm backend

[David Chisnall]

On 16/04/2020 02:15, Jordan Schidlowsky wrote:

https://twitter.com/lrz/status/1250453967957561344?s=21

I was also considering what it would take to build libobjc2 and base for 
wasm...


I’m guessing (David) the objc_msgsend could be implemented?  Our game 
runs pretty thin and WebGL looks like it can be swapped in for GLES 2.0 
and 3.0.


Currently, a load of the v2 ABI stuff is bracketed in clang on having an 
ELF target, but I believe that it should almost all work with wasm.  In 
particular, I believe lld correctly handles all of the exciting linkage 
types that we use.  We currently depend on using custom linkage types 
for the .ctors / .init pointer, which is ELF-specific, but probably 
could be made to work with wasm without too much difficulty.


objc_msgSend is an interesting case.  As I recall, W


Is there any interest from anyone else in a wasm backend?


Interested?  Yes.
Happy to take / review patches?  Yes.
Having time to actively work on it?  No.

David

Re: Is the GNUstep Objective-C runtime to picky about method signatures?

[David Chisnall]

On 13/04/2020 15:23, Wolfgang Lux wrote:

I've just recently come across a strange issue where the MySQL interface in the 
SQLClient library had stopped working with a weird error when using the 
libobjc2 runtime. In particular, the code was complaining that the 
backendQuery:recordType:listType: method was called without a loaded bundle. A 
debugging session later it was clear that the MySQL backend bundle was actually 
loaded into the program and that the backendQuery:recordType:listType: was 
available inside the bundle, but that the runtime simply refused to call the 
override and just called the implementation in the SQLClient base class 
instead, which emits the error message.
A more careful look at the code revealed a subtle difference between the 
definition of the backendQuery:recordType:listType: method in the SQLClient 
class and its MySQL bundle subclass: While the former (and all other backend 
bundles) uses id parameters for the record and list type arguments, the MySQL 
bundle was using Class parameters instead. This resulted in slightly different 
method signatures (@40@0:8@16@32 vs. @40@0:8#16#32 on a 64-bit architecture) 
and the libobjc2 method dispatch apparently is rather picky about those 
signatures. As I've already changed the SQLClient library to use consistent 
types, I've condensed the issue into a little test program (Test1.m) below. The 
output for this on macOS with Apple's Foundation looks like this (and for 
GNUstep with gcc and the gcc runtime it looks similar):


Calling a method with the wrong signature is undefined behaviour in 
Objective-C.  The Apple runtime just ignores the type entirely and will 
happily corrupt your stack in a few cases. We try to allow it in benign 
cases, which probably should include `Class` vs `id`, though I'm not 
entirely convinced: it's fine to pass a `Class` to something that 
expects an `id`, but passing an arbitrary object to something that 
expects a `Class` can cause exciting breakage.



And while I was writing that test program, I accidentally uncovered another bug 
in the libobjc2 runtime (see Test2.m): When calling super with a method that 
isn't implemented by the super class (or its own ancestors) libobjc2 simply 
does nothing, as if the method was called against nil.


This is a bug.  Please open an issue on GitHub so that I can track it.

David

Re: Next GNUstep release

[David Chisnall]

On 06/04/2020 12:56, Richard Frith-Macdonald wrote:

Yes, thanks to Ivan.

I have spent some time thinking about this, and while in the past I've argued 
against dropping ChangeLog (it's more convenient than the git logs, and of 
course is there for peple who download tarballs etc and don't have ready access 
to the repositories), but I think overall I kind of agree now.

It's very onerous to put comments in multiple places, but there is value to 
each of these things:
Technical information in the repository
ChangeLog for easier access
Announce/News for summary of important details.

What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, in 
that we could auto-generate ChangeLog entries from the repository, either by an 
automated commit hook or (assuming that's not easy to do readily), using a 
script to get details from the repository just before we make a realease, so 
that anyone getting a release of the software still gets a comprehensive 
ChangeLog.


I think that the place I'd disagree is that the ChangeLog is easier. 
That was probably true with GNA, somewhat true with viewvc (though 
debatable), but it isn't true with modern Git toolking (GitHub, GitLab, 
GOGS and so on).  Compare these two pages:


The ChangeLog file:
https://github.com/gnustep/libs-base/blob/master/ChangeLog

The Git history:
https://github.com/gnustep/libs-base/commits/master

The second is easier to skim, easier to jump to exact changes, and 
easier to use to isolate change in a particular area (only care about 
changes in the tools?  Look here: 
https://github.com/gnustep/libs-base/commits/master/Tools instead of the 
main history page).


The ChangeLog is more useable only for people who don't have web access 
(even if you download the tarball, you can still go to the web site to 
view the history and if you've done a git clone then you can view and 
search it offline easily).  The last of those is actually a valid reason 
for svn ChangeLog files that I missed: with svn, svn log was an online 
operation, so you couldn't do svn log / svn blame without a network 
connection, but you could read a ChangeLog.  With git, that is not a 
concern because log / blame are offline operations.


In terms of generating the ChangeLog entries automatically: I used to do 
this when we used svn.  I had a little script that would take an svn log 
and write a ChangeLog entry.  I didn't write the script, and when I 
looked no one had written a version that worked with Git.  I take this 
to mean that there is very little perceived requirement for ChangeLog 
files.  Having a non-canonical copy of information that has a canonical 
home doesn't seem valuable.  If people want it, then they can do a git 
log > MyOwnChangeLog.




Then we would be saved the overhead of writing ChangeLog entries and could 
concentrate on:
1. meaningful commit entries, which of course we should all be doing anyway;-)
2. writing release notes for any substantive change (rather than ChangeLog 
entries for even minor changes), to appear in the NEWS when we make a release


The second of these is the difficult bit, but it's *incredibly* 
valuable.  For the runtime, I try to update the ANNOUNCE doc as I go, 
but I still end up having to skim the git logs to check if I missed 
anything.  LLVM and FreeBSD both end up with manual steps and chasing 
contributors to update these just prior to release (FreeBSD has a 
'Release-Notes: Yes' thing you can put in the commit message so that the 
release engineer will look at it for things to put in release notes).



If we stop writing ChangeLog entries, we should be able to write release notes 
and still be spending less time, and of course that would make the process of 
cutting a release less onerous.

Does this seem a reasonable approach?


+1.

David

Re: Next GNUstep release

[David Chisnall]

I second that, thank you Ivan, but Fred your proposed solution is going 
to add more barriers to entry.


ChangeLog files made sense when people were submitting patches on the 
mailing list and distributing code in tarballs.


They were slightly anachronistic when CVS became standard for F/OSS 
projects and incorporated per-file change messages but they were still 
useful when people used them to describe the relationship between 
changes in multiple files.


They were mostly obsolete when projects moved to svn and commits became 
atomic. Commit messages then referred to a set of related changes, 
rather than to single files.  The one remaining argument for them was 
that VCS history may get lost in moves between revision control systems.


There was also a minor justification for them based on tooling: commit 
messages for svn were written after code review and some tools did not 
support reviewing the commit message along with the code (things like 
Phabricator did), so you could enforce a ChangeLog message in code 
review but you could not enforce a commit message at the same time.


We have now seen projects move from CVS to SVN and then to Git, 
preserving commit messages.  Git commits have evolved a structure that 
is well supported by a load of tooling (vim even gives nice syntax 
highlighting to ensure that you confirm to this structure, all of the 
Git GUIs, including GitHub, are designed to render it), where the first 
line is short and gives a very high-level summary of the changes and the 
remainder gives a detailed overview. No equivalent tooling exists for 
ChangeLog files.


In addition, a branch-and-PR workflow makes it possible to do code 
review of commit messages before merging.  Git makes it easy to edit and 
amend commit messages and force-push a branch, so individual commits can 
have their messages edited before a branch is merged.


I would much rather see code review enforcing good commit messages, 
which is a workflow that contributors to any other open source project 
will be familiar with.  I fail to see any benefit in having ChangeLog 
entries.


Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file 
that captures high-level user-visible improvements.  We don't 
necessarily need PR authors to write that, but the person merging a PR 
probably should if not.  This is far less granular than a commit message 
and serves a separate purpose.


David

On 05/04/2020 21:49, Fred Kiefer wrote:

Thank you Ivan for the great work you are doing here. And I promise to try to 
lighten the work on the next release by making sure every pull request gets it 
proper ChangeLog entry.

Fred


Am 05.04.2020 um 22:42 schrieb Ivan Vučica :

I have cut new releases:
- gnustep-make 2.8.0
- gnustep-base 1.27.0
- gnustep-gui 0.28.0
- gnustep-back 0.28.0

They've been pushed to GitHub as commits and signed-tags, signed using
GPG key of yours truly. The signed tags, interpreted as releases by
GitHub, have been marked as 'prerelease', and tarballs + GPG
signatures made using the maintainer key have been attached to them.
  https://github.com/gnustep/tools-make/releases/make-2_8_0
   https://github.com/gnustep/libs-base/releases/base-1_27_0
   https://github.com/gnustep/libs-gui/releases/gui-0_28_0
   https://github.com/gnustep/libs-back/releases/back-0_28_0

As a temporary download URL, they're also available at
  https://badc0de.net/gs/2020/
for anyone who does not use GitHub.

Please, have a go at them, and let me know if there are any critical
issues. Please particularly review ANNOUNCE files as these will
customarily go out to info-...@gnu.org. ANNOUNCE files should be the
same ones that have been committed into our Git repositories.

Please validate .sig files in case I made a mistake; that would be
rather embarrassing.

If there are none, one of the evenings next week I will:

- upload tarballs to the default distribution point at ftp.gnustep.org
- flip the 'prerelease' bit on GitHub
- send ANNOUNCE emails to info-...@gnu.org and to discuss-gnus...@gnu.org

as was done for previous releases.

Thank you everyone for your work! While preparing these was a lot of
work, I am also impressed by the amount of changes all across the
board: tons of new classes, tons of work on Android; very very
impressive amount of changes.

Incremental linking

[David Chisnall]

Hello,

For various reasons, I have been reading the binutils ld documentation 
and there is a note that -Ur is needed instead of -r for incremental 
linking of C++ programs that contain constructors.  I suspect that this 
is just badly written documentation - can someone try patching -make to 
use -Ur instead of -r and see if Additions links correctly with BFD ld?


David

Re: Building GNUstep for Windows using Clang

[David Chisnall]

On 05/03/2020 00:43, Frederik Seiffert wrote:
Thanks David. I made some progress with this setup, although it does 
feel like we’re a bit off the beaten track here (again)...


To get libobjc linking with the MinGW clang toolchain using LLD I had to 
create an import library (.dll.a) as outlined on the MinGW website:

http://www.mingw.org/wiki/CreateImportLibraries

Basically I ran "dumpbin /exports objc.dll" to get the list of symbols, 
used that to manually create a objc.def file, and then ran "dlltool -d 
objc.def -l objc.dll.a". One thing I noticed is that this doesn’t seem 
to include global variables (e.g. _objc_unexpected_exception), so these 
won’t be picked up by GNUstep configure and thus native exception 
support won’t work.


In the end however I switched to using the llvm-mingw toolchain 
(https://github.com/mstorsjo/llvm-mingw), which defaults to LLD and 
directly picks up the objc.lib without the need for the import library 
(but also doesn’t seem allow linking global variables).


I also had to remove "OBJ_MERGE_CMD_FLAG" in config.make, as LLD doesn’t 
support the -r flag for incremental linking.


Hmm, that probably means that -base Additions won't build.



With this and a couple more configure flags I got Base to start 
compiling, but I’m now stuck at the Additions subproject failing to link 
because it seems to be missing all the necessary linker flags:


clang -nostdlib        -o ./obj/subproject.o 
obj/Additions.obj/GSTypeEncoding.c.o ...

lld-link: error: : undefined symbol: _mainCRTStartup
lld-link: error: undefined symbol: _malloc
lld-link: error: undefined symbol: __declspec(dllimport) _object_getClass
...


Does anyone with better knowledge of GNUstep make have an idea of why 
this might happen or how to debug this further?


If you're not using -r, then I don't know what this .o will be.  The 
subproject thing is a source of constant pain because almost nothing 
other than GNUstep uses -r, so it tends to be horribly buggy.  It's 
supposed to take a load of .o files and generate a .o file that can be 
linked as if it were the original list of .o files.  Modern build 
systems just pass the list of .o files around.





There is a bug somewhere in the SEH support that I need to look for. 
 I suspect it is in clang - EH seems to fail with ARC and I think that 
it may be to do with the ARC calls not being correctly emitted in the 
funclet.  Dustin is planning on looking at some of the Clang funclet 
issues.


That’s good to know, thanks.

By the way, is libcxxrt needed on Windows for ObjC++ EH on Windows? 
Seems like WinObjC is not using it.



No, libcxxrt implements the Itanium C++ ABI.  On Windows, libobjc2 
supports the Visual Studio C++ ABI, so exceptions should interop with 
C++ libraries compiled with clang or MSVC.


David

Re: Building GNUstep for Windows using Clang

[David Chisnall]

Hi,



On 25/02/2020 16:55, Frederik Seiffert wrote:

Hi all,

I’m trying to build GNUstep for Windows using Clang and the 2.0 runtime 
ABI in order to have support for ARC and blocks, but I’m having some 
issues and general questions.


I’ve successfully built libobjc2 (as well as libdispatch) in a Visual 
Studio command prompt using CMake and clang-cl as recommended 
 (i.e. 
not using MinGW). Should these DLLs link/work when building GNUstep 
using MSYS2/MinGW?


Yes, they're native Windows DLLs, they should work with any Windows 
program, irrespective of what other DLLs it links (e.g. cygwin / msys). 
Note that the v2 ABI now has native support for SEH, so if you want 
exception interop and you want MinGW, you will need the toolchain 
variant that uses SEH, not Itanium-style DWARF unwinding.


There is a bug somewhere in the SEH support that I need to look for.  I 
suspect it is in clang - EH seems to fail with ARC and I think that it 
may be to do with the ARC calls not being correctly emitted in the 
funclet.  Dustin is planning on looking at some of the Clang funclet issues.


For me, building GNUstep base in MSYS2/MinGW fails during configure. 
Using LLD it doesn’t find objc.dll ("unable to find library -lobjc"). 
Using Gold gives different errors ("unrecognized emulation i386pep" and 
others). I’ve verified the library search paths.


As I’m pretty new to MinGW on Windows any general pointers are also much 
appreciated.


To the best of my knowledge, WinObjC works in this configuration but I 
do not know of anyone who has tried GNUstep (though I have no reason to 
suppose it won't work).


Note that, on Windows, the linker does not need to find objc.dll, it 
needs to find objc.lib.  You don't need objc.dll until you try to run a 
program (by default, Windows searches in the same folder as the .exe, so 
to run the tests CMake copies objc.dll into the Tests directory).  The 
Gold error looks as if you may have a 32-bit version of the DLL and be 
using a 64-bit toolchain?  WinObjC is not 64-bit clean, but GNUstep 
should be.  The runtime builds in either configuration (see the CI 
scripts - we build and test both in CI).


David

Re: Issues subclassing NSMutableArray

[David Chisnall]

On 24/02/2020 07:38, mickb...@posteo.net wrote:
Thanks for being patient with me: I am an expert C++ programmer, but 
with very few experience in Obj-C, even for a number of doubts like that 
one above.


The key difference is that constructors and operator::new in C++ are 
special in the language.  In Objective-C, +alloc and -init are just 
conventions with some API contracts.


[SomeClass alloc] is expected to return a new (uninitialised) instance 
of SomeClass, roughly analogous to calling operator::new, but it is not 
required to do so.  The only constraints on +alloc are that the returned 
object must implement the -init-family methods that SomeClass defines.


The memory management contract on +alloc is that it returns an owning 
reference.


Similarly, the constraints on -init are much weaker than those on a C++ 
constructor.  The -init family must return an object that is an instance 
of the class that was the result of the +alloc call or a subclass, or 
nil.  It does not have to be the receiver (though it is in the common 
case), and it is possible to report construction failure by returning nil.


The memory management contract on -init is that it consumes one 
reference on the receiver and returns an owning reference on the result. 
 In the common case, this is a no-op: if the receiver is the return 
value, there is no refcount manipulation.  Most init methods look 
roughly like this:


- (instancetype)init
{
if ((self = [super init]) == nil)
{
return nil;
}
// init code goes here
return self;
}

Note that this is respecting the -init contract on the superclass: when 
the subclass calls [super init], the superclass may substitute a 
different instance or may fail and return nil (consuming the reference 
to the receiver).


For class clusters, it's very common for the superclass to return a 
singleton from +alloc, which then selects a custom subclass based on 
which of the +init methods is called.  For example, in NSArray, you may 
get a singleton for a 0-element array, a special case for a one-element 
array, and have a subclass that allocates space at the end of it for all 
n-element arrays.  For something adaptive such as NSMutableArray, you 
may get a different initial hashing policy or data structure depending 
on how you initially fill the array, but this may change over time.


In particular, note that Objective-C classes can call object_setClass() 
to pivot their type dynamically, so if you have a class cluster for 
NSMutableArray it is completely valid to get back an instance of a 
subclass optimised for handing a handful of values and have that pivot 
to an instance that uses a completely different data structure when you 
add a load of elements.  In C++, you'd use double-dispatch for this 
(typically with static dispatch for the outer call), in Objective-C 
you're paying the price of dynamic dispatch all of the time and so you 
don't need to pay it twice.


When you want to create a subclass of a class cluster, you must provide 
the implementation of its primitive methods (e.g. -count, -addObject:, 
-objectAtIndex:).  You may choose to provide more efficient 
implementations of the others, but the superclass guarantees via an 
informal contract that it will implement everything in terms of these.


The checks for the explicit class in +alloc and -init-family methods in 
the class cluster implementation are to ensure that subclasses can call 
these methods and to forward them down to the root class (NSObject), 
without invoking the special-case behaviour.


In C++, you'd implement something equivalent via a combination of two 
classes:


1. An implementation of the shareable behaviour using the curiously 
recursive template pattern so that subclasses of the concrete type would 
inherit generic implementations where they didn't have an explicit override.
2. A facade class that would use the pImpl pattern to hide which 
implementation was in use and allow the current implementation to be 
replaced dynamically.


David

Re: base / libobjc2 link issues on FreeBSD 12

[David Chisnall]

On 20/02/2020 15:08, Riccardo Mottola wrote:

freebsd 12.1 system compiler is clang 8.0.1


Yup, just checked, it is on my system too and it appears to work.

I added these options because they are mentioned like this in your 
INSTALL file!


My fault.  I've fixed that now.



Just as a test, I did again a  clean build with absolutely no options, 
just:

cd Build
$ cmake ..
-- The C compiler identification is Clang 8.0.1
-- The ASM compiler identification is Clang
-- Found assembler: /usr/bin/cc
-- The CXX compiler identification is Clang 8.0.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Testing C++ interop
-- Testing /usr/lib/libcxxrt.so as the C++ runtime library
-- Using /usr/lib/libcxxrt.so as the C++ runtime library
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- GNUstep install type set to SYSTEM
-- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES
-- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/multix/code/gnustep-cvs/libobjc2/Build


Looks identical to what I see.



make -j2

< build...>

-> all 178 tests fail.

where are the errors of the tests?


You ran ctest?  Adding --output-on-failure will show the errors.  You 
can also just run any of the test binaries individually.


I can't reproduce this though.  Doing exactly the same steps as you on a 
fresh clone on a FreeBSD 12 system, ctest -j200 finishes with:


100% tests passed, 0 tests failed out of 178

Total Test time (real) =   4.03 sec

David

Re: base / libobjc2 link issues on FreeBSD 12

[David Chisnall]

On 20/02/2020 11:01, Riccardo Mottola wrote:
cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang 
-DCMAKE_ASM_COMPILER=clang -DCMAKE_ASM_FLAGS=-c


clang++ is a C++ compiler, clang is a C compiler, so your 
CMAKE_CXX_COMPILER value looks wrong.  Clang is the default compiler on 
FreeBSD, so these seem redundant (I don't know why you are adding -c to 
ASM flags either). I don't know if the system clang on FreeBSD 12 is 
sufficiently new, the package uses clang80.


David

Re: base / libobjc2 link issues on FreeBSD 12

[David Chisnall]

On 20/02/2020 07:19, Riccardo Mottola wrote:

ld-elf.so.1: /System/Library/Libraries/libobjc.so.4.6: Undefined symbol
"_ZNSt3__14cerrE"
configure:7880: $? = 1
configure: program exited with status 1


This looks as if something is including a C++ header that is pulling in 
iostream, specifically the libstdc++ version of iostream.  libstdc++ is 
not installed by default on FreeBSD, so I'm not sure how that's 
happening.  Do the libobjc2 tests also fail with this error?


David

Re: Instance variables overwritten by other assignments

[David Chisnall]

On 26 Dec 2019, at 01:32, Patryk Laurent  wrote:
> 
> 
> Hi David,
> 
>> On Dec 25, 2019, at 01:19, David Chisnall  wrote:
>> 
>> Hi,
>> 
>> This sounds like the issue with the Linux run-time linker and the 1.x 
>> non-fragile ABI.  This can be fixed by either:
>> 
>> 1. Using pretty much any non-Linux OS, or
>> 2. Using the 2.0 ABI and clang 8.0 or later.
>> 
> 
> Brilliant — that did it, thank you! Everything is running smoothly and 
> snappily on Aarch64 with clang9 and the 2.0 runtime. 

Yay!

David

Re: Instance variables overwritten by other assignments

[David Chisnall]

Hi,

This sounds like the issue with the Linux run-time linker and the 1.x 
non-fragile ABI.  This can be fixed by either:

1. Using pretty much any non-Linux OS, or
2. Using the 2.0 ABI and clang 8.0 or later.

David

> On 25 Dec 2019, at 04:02, Patryk Laurent  wrote:
> 
> Hi,
> 
> At Gorm startup I am seeing a problem where Boolean assignments in 
> -initDefaults are somehow overwriting memory for NSTableView.m’s 
> _numberOfColumns instance variable.  See the output of debug print statements 
> below. 
> 
> Does anyone know why this might be happening — and how to fix it?
> 
> This is under clang-6.0 on Aarch64. 
> 
> Thank you,
> Patryk
> 
> GNUstep-build/apps-gorm/Gorm.app$ ./Gorm 
> 2019-12-25 03:51:47.959 Gorm[4257:4257] Bad palette selection - -1
> 2019-12-25 03:51:48.002 Gorm[4257:4257] Bad palette selection - -1
> 2019-12-25 03:51:48.267 Gorm[4257:4257] Bad palette selection - -1
> 2019-12-25 03:51:48.314 Gorm[4257:4257] NSTableview.m:2012: _isValidating 
> = NO; // _numberOfColumns is 0
> 2019-12-25 03:51:48.315 Gorm[4257:4257] NSTableview.m:2013: _drawsGrid
> = YES; // _numberOfColumns is 0
> 2019-12-25 03:51:48.315 Gorm[4257:4257] NSTableview.m:2014: _rowHeight
> = 16.0;  // _numberOfColumns is 0
> 2019-12-25 03:51:48.315 Gorm[4257:4257] NSTableview.m:2015: _intercellSpacing 
> = NSMakeSize (5.0, 2.0); // _numberOfColumns is 0
> 2019-12-25 03:51:48.316 Gorm[4257:4257] NSTableview.m:2016; 
> ASSIGN(_selectedColumns, [NSMutableIndexSet indexSet]); // _numberOfColumns 
> is 0
> 2019-12-25 03:51:48.316 Gorm[4257:4257] NSTableview.m:2018: 
> _allowsEmptySelection = YES;  // _numberOfColumns is 256
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2019: 
> _allowsMultipleSelection = NO; // _numberOfColumns is 256
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2020: 
> _allowsColumnSelection = YES; // _numberOfColumns is 65792
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2021: 
> _allowsColumnResizing = YES;  // _numberOfColumns is 16843008
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2022: 
> _allowsColumnReordering = YES;  // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2023: // 
> _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2024; _selectingColumns 
> = NO; // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.317 Gorm[4257:4257] NSTableview.m:2025: 
> _verticalMotionDrag = NO; // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2026:_editedColumn = 
> -1; _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2027: _editedRow = -1; 
> // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2028: _clickedRow = -1; 
> // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2029: _clickedColumn = 
> -1;  // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2030: _selectedColumn = 
> -1; // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.318 Gorm[4257:4257] NSTableview.m:2031:  _selectedRow = 
> -1;  // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.319 Gorm[4257:4257] NSTableview.m:2032: 
> _highlightedTableColumn = nil; // _numberOfColumns is 4311810304
> 2019-12-25 03:51:48.319 Gorm[4257:4257] NSTableview.m:2036: 
> ASSIGN(_sortDescriptors, [NSArray array]); // _numberOfColumns is 4311810304
> Segmentation fault
> 

Re: Working on XIB document support

[David Chisnall]

Hi Fred,

I have some fairly recent .xibs in this project, which aims to be an 
OmniOutliner 3 clone (because I hate OmniOutliner 5 and 3 doesn't work 
on recent macOS):


https://github.com/davidchisnall/OpenOutliner

I haven't worked on it for a while (the undo stuff is completely broken 
and needs reworking from scratch - maybe over Christmas I'll play with 
it), but it's good enough for me to use with the OmniOutliner files that 
I have.


It does depend on correct handling of weak properties in the controller 
classes, but hopefully the KVC implementation will just call the 
property accessors and that will just work.


I don't think that the code will work with GNUstep very easily because 
it depends on the view-based NSTableView, which wasn't implemented last 
time I looked.


David

On 09/12/2019 09:46, Fred Kiefer wrote:

I just want to let you know that I have started to integrate the
Eggplant code for XIB document loading, that is the newer XIB format,
into GNUstep gui. Over the weekend I managed to integrate a minimal
version of the code into a git branch and get it compile with gcc. The
next step is to clean up the code further and test it with some real XIB
files. That is why I am writing to you :-)

I am looking for some real live applications where you have modern XIB
files and would like to reuse these on GNUstep. Preferable without
custom classes otherwise you will have to provide the source code as well.

Don't expect too much from this effort. I have a week off from work (too
much holidays left) but there are other competing projects I plan to
spend time on:
- Perparring house and garden for the winter
- Go to the Hans Baldung Grien exhibition in Karlsruhe or spend a day up
in the Black forest
- Plenty of reading to catch up with
- Help a befriended company with their software issues
- Plus plenty of smaller stuff that needs to be taken care of

Cheers,
Fred

Re: Debugging on Linux with non-fragile ABI?

[David Chisnall]

On 18/11/2019 11:04, Richard Frith-Macdonald wrote:

Interesting.  I'd very much like to see support for nonfragile objects in 
debuggers.
How could this work for core dumps?  Is it even possible to examine instance 
variables in core dumps when the nonfragile ABI is used?


If someone wants to do the integration work, I don't see why not. 
Non-fragile IVar layouts are described here:


https://github.com/gnustep/libobjc2/blob/108d4e19c0ed5443419279ab9998bc93da7d3f19/ABIDoc/abi.tex#L282

In summary, the offset is stored in a variable with the name:

__objc_ivar_offset_{class name}.{ivar name}.{type encoding}

There are a few complexities from the non-fragile model.  In particular, 
consider two classes, A and B, where B is a subclass of A.  The 
non-fragile ABI allows A and B to both define an ivar v.  There will; 
however, be only one:


__objc_ivar_offset_A.v.{something}

And only one:

__objc_ivar_offset_B.v.{something}

Starting from an object pointer and looking for an ivar called v, you 
first need to check that the low {1,3} bits (for {32,64}-bit platforms) 
are 0.  If they are not, then you need to look in the SmallObjectClasses 
array to find the class.  This is an array of class pointers, indexed by 
the low bits.  If the low bits are 0, then this is a pointer[1].


If it is a small object, then you don't have any ivars, but you can call 
methods on it that will handle data stored in the top bits.


If it is not a small object, you can follow the class pointer and look 
at its name field.  You can then look for any globals matching the pattern:


__objc_ivar_offset_{class name}.v.{anything}.

If you find one, then you can add this offset to the object pointer and 
get the ivar.  If you don't, then follow the super-class pointer and try 
again.


If the prompt has an explicit cast to a superclass in it then you can 
start at the expected class.  If you want to build a list of all classes 
in the system then walk all of the sections for each module that contain 
classes.


David

[1] For now.  The Apple runtime steals the top 16 bits to store the 
refcount and I'd like to do that at some point as well, which should 
reduce object sizes.

Re: Debugging on Linux with non-fragile ABI?

[David Chisnall]

Hi,

Neither debugger currently knows anything about the non-fragile ABI. 
The Apple runtimes have a few introspection functions that are called 
without acquiring the necessary locks, which are intended to be called 
by the debugger, but someone needs to write the relevant code in either 
gdb or lldb and let me know what hooks they'd like.  The lldb code is 
relatively approachable and the Objective-C runtime interfaces are quite 
well abstracted, so it would be fairly simple to add.


Note that lldb probably does not give you the correct layout, especially 
for anything that is not a base class.  It looks as if it's relying on 
the compiler's guess of where ivars will be, which is not always correct 
in the non-fragile ABI.


Materialising ivar offsets is relatively easy.  The change is basically 
to use a different symbol name for the ivar offsets.


If no one has the time or inclination to do this, then I'd recommend 
calling the runtime introspection functions directly from the {g,ll}db 
command line.  These will give you the correct layouts.  It's a little 
bit clunky (though would be easy to wrap in a plug-in function), but 
these can give you the type and offset of each ivar and let you write 
some pointer arithmetic that shows you the correct ivar.


David

On 18/11/2019 09:12, Frederik Seiffert wrote:

Hi Wolfgang,

We’re running into very similar issues debugging using lldb with the GNUstep 
Android toolchain, which is using the modern (v2) ABI. Have you been able to 
get any further with this?

The following lldb command seems to indicate that the root cause might be lldb 
missing knowledge about the ObjC runtime. Could you check if you get the same 
output for this?


(lldb) language objc class-table dump
error: current process has no Objective-C runtime loaded


Thanks,
Frederik



Am 18.06.2019 um 02:49 schrieb Wolfgang Lux :

Hi all,

has anybody tips for how to debug GNUstep executables built with the
non-fragile ABI?
Gdb seems pretty useless with the non-fragile ABI because all instance variable
offsets appear to be 0 so it's impossible to inspect the contents of any
instances:
(gdb) print *self
$1 = {<> = {isa = 0x6074f8 <_OBJC_CLASS_Test>},
   name = 0x6074f8 <_OBJC_CLASS_Test>, value = 0x6074f8 <_OBJC_CLASS_Test>,
   parent = 0x6074f8 <_OBJC_CLASS_Test>, children = 0x6074f8 <_OBJC_CLASS_Test>}

I've also tried lldb, which at least understands the object layout:
(lldb) print *self
(Test) $0 = {
   NSObject = {
 isa = 0x006074f8
   }
   name = 0x00607588
   value = 0x00607588
   parent = nil
   children = 0x007949b8
}
However, when I try to inspect any of the instance attributes I only get an
error message:
Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol
OBJC_IVAR_$_Test.name
error: The expression could not be prepared to run in the target
(lldb) print self->value
Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol
OBJC_IVAR_$_Test.value
error: The expression could not be prepared to run in the target

I've checked this on Ubuntu 18.04 with lldb 6.0 (and before any FreeBSD
advocates run in, it's exactly the same on FreeBSD 11.3 which comes with lldb
8.0)

All of this works fine on macOS:
(lldb) print *self
(Test) $0 = {
   NSObject = {
 isa = Test
   }
   name = 0x00013118 @"$"
   value = 0x00013118 @"$"
   parent = nil
   children = 0x000100305910 2 key/value pairs
}
(lldb) print *self->name
(NSString) $1 = {
   NSObject = {
 isa = __NSCFConstantString
   }
}
(lldb) print self->name
(__NSCFConstantString *) $2 = 0x00013118 @"$"

Wolfgang

Re: Gitflow proposal

[David Chisnall]

FWIW: Both internally and for public projects, at $WORK we use feature 
branches and PRs, so I concur with Fred here.  GitHub lets 
administrators commit changes without review, which we sometimes do for 
things like tweaks to comments and so on, but generally don't for 
anything involving a code change (or, if we do, at least wait until it's 
passed CI).  Having a test suite that's parallelisable helps a lot here: 
The GitHub CI / Azure Pipelines executors are 4-core machines, so 
running the tests in parallel helps a lot with turn-around times.


David

On 15/11/2019 08:16, Fred Kiefer wrote:

First off before I explain why I am strongly against Gitflow let me restate 
that I advocate feature branches and pull requests. But I will come back to 
that in the end.

A software workflow should match the organisation and purpose of a project and 
the people that defined Gitflow are well aware of that. They describe what sort 
of projects Gitflow is suited for. GNUstep does not meet that criteria. Even in 
the place where I work we decided against Gitflow as it is not well suited for 
our processes. I could go into details here but I believe you are all able to 
follow the link below and read the description.

Also it won’t work. Nobody is getting payed to review pull requests on GNUstep. 
If I started to write pull requests for GNUstep gun, they would be sitting 
there for a year or so without anybody noticing.

The bigger problem is that even Gitflow won’t help us with our quality issues. 
Over the last few months I have tried to provide comments to most of the pull 
requests in the GNUstep repository. I do this a lot at work and doing so comes 
naturally to me. Most of the developers react positive by fixing the issues I 
point to. There is one exception and please look it up in git to see the 
difference. In that case many of my comments did get ignored others, where 
flagged as done although no change was made and sometimes branches where merged 
even when travis reported them as broken or while I had objected merging them. 
So even a workflow that enforces all this is of no use in this case.

And it could be even worse. With Gitflow in place as a rule, Riccardo and I 
could have been stopped from doing the emergency fixes we did last night to get 
master compiling again (and not only for gcc, Riccardo's change must have fixed 
compilation of clang as well). As long as we have rogue developers with full 
permissions out there, we need ways to counteract.

So yes, let's use more branches and pull requests but especially those 
developers that break the build. And if we ever manage to get them to follow 
that rules we might start to think about more process.

Fred


Am 15.11.2019 um 05:30 schrieb Gregory Casamento :

Guys,

I must say this.  I have been trying to, in general, hold myself to doing this 
rather formally up until recently.  I admit that I have been more directly 
pushing things in as of late.

Since, as you say, this could have been avoided by doing PRs... which it could 
have.  Should we not, as an project, move to this model?  It's known as gitflow 
and it's what I was following when I would create a branch with large changes 
and then have it reviewed by yourself and others before merging.   This would 
slow some development down, but it would have the effect of keeping master in a 
condition where it always builds and is always releasable (which should always 
be the case).

Here is a link, for reference: 
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Some might argue that this should only be done with large teams, but I used 
this process on a small team when I worked at a company known as customink 
where we only had 4 people and it still helped things go very smoothly.

This is the process I've been trying to adhere to.  I would advocate that, if PRs could 
have prevented this then, perhaps, we should all move to it.  I had a discussion with 
Riccardo where he thought this process was too much and was silly and that merging to the 
master branch directly is always the best way to go.   That's precisely what caused this. 
  We can make all of the arguments that "a focused developer wouldn't make these 
mistakes" but that's BS.  Process is here to prevent mistakes or to mitigate them.

I disagree with Riccardo's position wholeheartedly.   A more controlled and 
disciplined approach should be adopted and we should stick to it.

Any thoughts?

Yours, GC

Re: What is the official bug tracker?

[David Chisnall]

On 12 Nov 2019, at 15:55, Gregory Casamento  wrote:
> 
> Github

GitHub is the official bug tracker for libobjc2, but I believe that the 
consensus on the list for the remainder of the project was not to move to 
GitHub.  I don’t particularly agree with that consensus, but I don’t believe 
that it should be unilaterally overridden.

David

Re: Embedded blocks...

[David Chisnall]

On 27/10/2019 16:05, Gregory Casamento wrote:
We are a GNU / FSF project.  Dropping support for GCC would be bad 
political mojo.   There is little we can do to bridge the gap other than 
doing these macros.


I don't really understand how this works.  GCC does not support a 
post-2005 dialect of Objective-C.  GNUstep is a framework that aims to 
provide an implementation of the 2019 Objective-C standard library.  Why 
is it politically problematic for GNUstep to drop support for GCC, but 
not problematic for GCC to drop support for GNUstep?


For what it's worth, I've spoken to a couple of GCC devs over the last 
few years about supporting modern Objective-C (because I would like us 
to have a choice of compilers), but the effort involved for them is huge 
(even a naive ARC implementation is a big piece of effort) and the 
return is small (why would anyone use it?  Basically, the only target 
market is GNUstep developers on platforms that Clang doesn't support, 
which I think is a set containing only Riccardo).  There is some 
interest in supporting blocks, because Apple's libc headers no longer 
support compilers that don't support blocks, but even then I haven't 
seen much progress from GCC.


David

Re: Creating a block using the Macros....

[David Chisnall]

This is not possible in the general case.

A block is a structure containing:

 - A pointer to the invoke function.
 - The type info for the call.
 - A set of references to captured variables including:
   - Helpers to destroy any captured variables.
   - Helpers to copy any captured variables.

C macros are nowhere near expressive enough for this.  You could 
probably (just about) implement them using C++ templates, though it 
would be a lot of work.


The block macros give a way of allowing functions / methods that take 
blocks to be called, so that it is possible to build GNUstep with GCC 
and link it to a program built with clang.  To date, anything that needs 
to create blocks, we have implemented a different way or conditionally 
compiled out when building with GCC.


David

On 27/10/2019 15:55, Gregory Casamento wrote:
How do I create a block using the macros?  I know how to declare one, 
but not actually create one.   Doing it in clang is easy, but I need 
something that will work for both


Any ideas?

GC
--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Mailtrack 
 
	Sender notified by
Mailtrack 
 
10/27/19, 11:53:53 AM 	

Re: libobjc2 relocation issue in aarch64

[David Chisnall]

I think the main hint is to use a dynamic library.  Static linking is not well 
tested on any platform and the assembly code expects a PIC model.  I’m happy to 
accept patches that improve the static linking experience, but it’s not 
something that I have any plans to work on personally.

David

> On 17 Jul 2019, at 20:43, Jordan Schidlowsky  wrote:
> 
> I can't seem to get libobjc2 to link in properly to my android app on 
> arm64-v8a.  I'm using the latest clang prebuilt by Frederik here: 
> https://github.com/gnustep/tools-android
> 
> I've tried 3 different linkers, and all report the same 
> R_AARCH64_ADR_PREL_LO21 issue.  bfd was the only linker to provide any 
> insight, but it seems like it's related to the SmallObjectClasses symbol.   
> Output from each linker is below:
> 
> gold:
> libs/libobjc2/objc_msgSend.aarch64.S:97: error: relocation overflow in 
> R_AARCH64_ADR_PREL_LO21
> 
> lld:
> ld.lld: error: 
> ../../../../libs/libobjc2/objc_msgSend.aarch64.S:97:(.text+0xD0): relocation 
> R_AARCH64_ADR_PREL_LO21 out of range: 16077624 is not in [-1048576, 1048575]
> 
> bfd:
> libs/libobjc2/libobjc.a(objc_msgSend.S.o): In function `objc_msgSend_stret': 
> libs/libobjc2/objc_msgSend.aarch64.S:97:(.text+0xd0): relocation truncated to 
> fit: R_AARCH64_ADR_PREL_LO21 against symbol `SmallObjectClasses' defined in 
> COMMON section in libs/libobjc2/libobjc.a(class_table.c.o)
> 
> 
> Any thoughts?
> -Jordan


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Why doesn’t the Unix makefile build work on windows with clang and msys2

[David Chisnall]

As I have repeatedly said:

libobjc2 has no dependency on anything other than Windows.  It needs a Windows 
build environment.  It does not need MinGW.  It does not need Cygwin.

When you build it on Linux, it does not need WINE.

Building it on Windows requires following a small number of documented steps.  
I haven’t tried the UNIX Makefiles output on Windows (I use Ninja on all 
platforms, because it is faster), so there may be some bugs specific to that 
output from CMake.  Patches welcome.  

David


> On 4 Jul 2019, at 18:46, Gregory Casamento  wrote:
> 
> I couple of months ago I was trying this but was instructed to do a build 
> with visual studio.   I’m wondering if cmake is being pushed as a replacement 
> for gnustep-make then why is it so difficult to build this simple library 
> using this so called universal make tool?
> 
> GC 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Errors compiling Libobjc2

[David Chisnall]

> On 2 Jul 2019, at 23:23, Riccardo Mottola  wrote:
> 
> Hi,
> 
> On 2019-06-21 16:13:58 + David Chisnall  
> wrote:
> 
>> On 21/06/2019 16:08, Riccardo Mottola wrote:
>>> ld: error: undefined symbol: _Unwind_Resume
>> It looks as if your toolchain doesn't automatically link anything that 
>> provides the exception ABI.  On most *NIX systems this comes from something 
>> called libgcc_s.so (which, on FreeBSD, is actually LLVM's compiler-rt - on 
>> some platforms it's installed as such).  What happens when you compile a C 
>> program that uses -fexceptions and __attribute__((cleanup)) on OpenBSD?  
>> Does it link something that provides these symbols?
> 
> I did some research and found that Unwind_Resume is in libc++, however to get 
> all Unwind symbols, libc++abi is needed.

_Unwind_Resume should not be in libc++, it’s from the unwind library, which is 
two layers down.

Note that if you’re on a platform that uses libc++abi, then C++ / Objective-C 
exception interop won’t work.  Please encourage OpenBSD to use libcxxrt or 
libsupc++ instead.  libc++abi is not a drop-in replacement for libsupc++.

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Errors with NS_DURING et al exception handling when building with clang

[David Chisnall]

It sounds as if you’re missing the NSException.h header.  NS_DURING is the 
ancient NeXT-era exception handling macro, which expands to @try { on a vaguely 
modern version of Objective-C (i.e. anything after about 2004, GCC or Clang).  
It shouldn’t be used in new code.

David

> On 30 Jun 2019, at 02:52, Gregory Casamento  wrote:
> 
> GSXML.m:4147:3: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> 
> 
> 
> 
> GSXML.m:4202:3: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> GSXML.m:4256:3: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> GSXML.m:5365:7: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> GSXML.m:5401:3: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> GSXML.m:5433:3: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> GSXML.m:5468:3: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> GSXML.m:5503:3: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> GSXML.m:5530:3: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
>   ^
> GSXML.m:5747:7: error: use of undeclared identifier 'NS_DURING'
>   NS_DURING
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Errors compiling Libobjc2

[David Chisnall]

On 21/06/2019 16:08, Riccardo Mottola wrote:

ld: error: undefined symbol: _Unwind_Resume


It looks as if your toolchain doesn't automatically link anything that 
provides the exception ABI.  On most *NIX systems this comes from 
something called libgcc_s.so (which, on FreeBSD, is actually LLVM's 
compiler-rt - on some platforms it's installed as such).  What happens 
when you compile a C program that uses -fexceptions and 
__attribute__((cleanup)) on OpenBSD?  Does it link something that 
provides these symbols?


David

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

libobjc2 updates

[David Chisnall]

Hello the list,

A kind volunteer gave me access to a BeagleBone Black running FreeBSD, 
so I have now been able to test the runtime with ARM (AArch32) and fixed 
a few issues:


 - [Probably FreeBSD specific], on ARM .init_array initialisers are 
run, but .ctors are not, so the compiler needs to use .init_array for 
the call into the runtime to register a binary.  This is now fixed in 
upstream LLVM.


 - The ARM objc_msgSend implementation no longer uses text relocations, 
so can be mapped read-only in the process.  This should fix it on 32-bit 
Android.  I also have a patch in the related issue for AArch64 - anyone 
with a 64-bit ARM system handy, please test it!


 - The C++ exception structure used by the runtime did not incorporate 
the extra fields that the ARM EH ABI adds.  This caused some state 
corruption with Objective-C++ exceptions and is now fixed.


 - [Possibly FreeBSD specific] the GNU unwinder on ARM appears to not 
quite follow the ARM EH ABI spec.  It calls the personality function to 
install the handler without doing a phase-1 search.  This is now worked 
around in the runtime.


The runtime (master branch, due to be released as 2.0) now passes all of 
the tests on ARM, except for a small number that are not architecture 
specific, but run out of memory on the test platform.


I've also fixed a few other bugs:

 - A memory leak in @synchronized that Fred pointed out.  We only 
leaked a few bytes for every object used with @synchronized, but in a 
loop it was easy for this to be a problem.  I had not seen this issue 
because I avoid using @synchronized entirely.  It is a horrible feature 
in Objective-C and using __attribute__((cleanup)) for the unlock in C 
(or RAII in C++) lets you accomplish the same thing with less 
inefficiency.  The feature wouldn't be such a problem if it were defined 
to send -lock / -unlock messages to the object, but requiring the 
runtime to maintain a lock for each object is awkward.


 - There was an issue with static builds where the Protocol class was 
not being linked unless explicitly used outside of the runtime.  This, 
in turn, broke the runtime's detection that the __objc_load function was 
being called for the runtime itself, which broke the ABI mismatch 
detection.  This is now fixed and static linking probably works again.


 - The compiler occasionally emits negative offsets for ivars in the 
non-fragile ABI when, in the fragile ABI version of the class they would 
be within the space allocated by the superclass.  The runtime was not 
handling this correctly and so we were ending up with nonsense 
(sometimes negative) offsets for classes that contained BOOLs as their 
first fields if the compiler could see the layout of the superclass and 
it ended with something less than the size of a pointer.  This triggered 
some very odd behaviour in -gui with some non-default defaults values 
set (and almost certainly broke GSMime, though I didn't see any reports 
of that).


I have now tested and committed Dustin Howett's patches to clang for 
improving the Windows support.  It is now possible to use upstream clang 
(master branch, not any releases yet) to build WinObjC and have all of 
the tests pass (with some not-yet-merged patches to WinObjC, including 
updating their copy of libobjc2 to a recent trunk).


On Windows, we now have fully interoperable exceptions: The 2.0 ABI uses 
SEH-compatible exceptions and Objective-C++ code compiled with clang-cl 
will use the same ABI as the visual studio compiler for C++.


I have now moved the CI over to using Azure Pipelines, so there are CI 
builds on Windows and Ubuntu.  This should help avoiding regressions on 
Windows.


If you see any other issues, please report them on GitHub!

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Commit process to source tree on github

[David Chisnall]

Hi,The best thing to do for nontrivial changes (even if you do have commit access) is send a PR, because then someone can do pre-commit review.DavidOn 23 Mar 2019, at 00:42, Sergii Stoian  wrote:Hello everybody,I plan to commit some changes/fixes to GUI and Back.My last GNUstep commit was long time ago to SVN at gna.org. I'm familiar with git and github.My question is: what is the correct way to submit patches/fixes? Should it be a pull request for approval?May I commit directly to the source tree on github?-- Sergii Stoian, ProjectCenter lead developerNEXTSPACE owner, lead developer___Gnustep-dev mailing listGnustep-dev@gnu.orghttps://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: libobjc2 compilation error with clang

[David Chisnall]

On 20/02/2019 07:14, Gregory Casamento wrote:
I downloaded this when updating GNUstep.  If you look at the script in 
tools-scripts/update-gnustep it pulls the latest from all repos and then 
does a build with the script compile-gnustep.   This is simply to update 
my installation on Linux.  This has been working up until recently.


Does the CMakeLists.txt file look like this one?

https://github.com/gnustep/libobjc2/blob/master/CMakeLists.txt

The line that it's complaining about (assuming that you didn't truncate 
the error message) is line 64.  In libobjc2 trunk, that is right in the 
middle of the list of header files to include and there is absolutely no 
way that this line would generate an error (if it contained an error, 
cmake would report it at the start or end of the set command).


The traceback is complaining about usage of find_package, but this 
CMakeLists.txt file does not use find_package at all.  As such, I have 
no idea what you are building, but it doesn't appear to be libobjc2.


David

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: libobjc2 compilation error with clang

[David Chisnall]

> On 19 Feb 2019, at 05:30, Gregory Casamento  wrote:
> 
> 
> 
> CMake Error at 
> /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 
> (message):
>   Could NOT find kqueue (missing: KQUEUE_INCLUDE_DIRS)
> Call Stack (most recent call first):
>   /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:378 
> (_FPHSA_FAILURE_MESSAGE)
>   cmake/Findkqueue.cmake:20 (find_package_handle_standard_args)
>   CMakeLists.txt:64 (find_package)
> 
> 
> Isn't kqueue specific to BSD?

What is this the build for?  Line 64 of libobjc2’s CMakeLists.txt isn’t a 
find_package invocation.

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Building on android....

[David Chisnall]

On 13/02/2019 14:41, Jordan Schidlowsky wrote:
An NDK app can chose to bundle in a (c++_shared) library in your app, or 
you can link with a static (c++_static) standard library.   This is 
actually dependant on what setting you chose for this in your gradle 
build file, as gradle will pass that along to cmake which will link it in.


That cxx runtime test doesn't quite work correctly using an android 
toolchain.  But if you want to configure your ndk app using c++_static 
you can remove that test section from CMakeLists.txt and add in manually 
below:


set(CXXRT_IS_STDLIB true)
target_link_libraries(objc c++_static stdc++)

I will also note, that I am still thinking about a way to run that test 
suite while cross compiling...


Patches to the cmake very welcome!  I believe that the test really just 
needs to check if the program links correctly, not if it works.  I'm 
only running it because that works on platforms where programs will 
successfully link against DSOs that don't provide all of the symbols 
that they'll need.


David

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Building on android....

[David Chisnall]

As I understand it (and this is based on looking a few years ago, so may 
be wrong now) the NDK doesn't provide any C++ environment by default, 
you have to explicitly opt in to one.  It used to provide a choice of 
two, I don't know if it still does.


David

On 13/02/2019 12:41, Gregory Casamento wrote:
A little more context...  my build environment is a MacPro 2010 running 
the latest version of Mojave.  I have downloaded and installed the 
latest of Android studio and installed the latest SDK and NDK using the 
menu under tools and the SDK manager.  The version of the NDK I'm using 
is 19.0.5232133.   I am utterly stumped as to why this is not working.  
Also, it seems as though Ivan's installation of this is working which 
seems to indicate that this is a configuration issue.


Any input would be appreciated.

On Wed, Feb 13, 2019 at 7:09 AM Gregory Casamento 
mailto:greg.casame...@gmail.com>> wrote:


### Build libobjc2

-- The ASM compiler identification is Clang

-- Found assembler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang

-- Check for working C compiler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang

-- Check for working C compiler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang
-- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

-- Detecting C compile features

-- Detecting C compile features - done

-- Check for working CXX compiler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++

-- Check for working CXX compiler:

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
-- works

-- Detecting CXX compiler ABI info

-- Detecting CXX compiler ABI info - done

-- Detecting CXX compile features

-- Detecting CXX compile features - done

-- Testing C++ interop

-- Testing C++ standard library

-- No useable C++ runtime found

-- Looking for pthread.h

-- Looking for pthread.h - found

-- Looking for pthread_create

-- Looking for pthread_create - found

-- Found Threads: TRUE

-- GNUstep install type set to NONE

-- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES

-- Performing Test CXA_ALLOCATE_EXCEPTION_NOEXCEPT_COMPILES - Success

-- Configuring done

-- Generating done

-- Build files have been written to:

/Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build


/Users/heron/Development/Algoriddim/gnustep-toolchain/gnustep-android/gnustep/libobjc2/build/CMake

[1/1] Linking CXX executable test_cxx_runtime

FAILED: test_cxx_runtime

: &&

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++
--target=armv7-none-linux-androideabi16

--gcc-toolchain=/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64--sysroot

/Users/heron/Library/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/darwin-x86_64/sysroot
-g -DANDROID -fdata-sections -ffunction-sections -funwind-tables
-fstack-protector-strong -no-canonical-prefixes -mfpu=vfpv3-d16
-fno-addrsig -mthumb -Wa,--noexecstack -Wformat
-Werror=format-security -stdlib=libc++-Wl,--exclude-libs,libgcc.a
-Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id
-Wl,--warn-shared-textrel-Wl,--exclude-libs,libunwind.a
-Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack
-Wl,-z,relro -Wl,-z,now -Wl,--gc-sections
CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o-o
test_cxx_runtime-latomic -lm && :

CMakeFiles/test_cxx_runtime.dir/typeinfo_test.cc.o:typeinfo_test.cc:vtable
for type_info2: error: undefined reference to
'std::type_info::__do_upcast(__cxxabiv1::__class_type_info const*,
void**) const'

clang++: error: linker command failed with exit code 1 (use -v to
see invocation)

ninja: build stopped: subcommand failed.

### LIBOBJC2 BUILD FAILED!!!


I am running into the above error when trying to build for Android. 
I have the latest ndk and sdk installed with Android studio.  Does

anyone have any idea offhand why C++ isn't finding it's runtime?   I
will attach the build script I am using to generate the ninja script

GC

-- 
Gregory Casamento

GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org


- http://heronsperch.blogspot.com


http://ind.ie/phoenix/

Re: Cutting a release?

[David Chisnall]

On 01/01/2019 11:44, Ivan Vučica wrote:

Hi maintainers,

If you want, I can spend some time cutting a release. It has been a 
while since the last one. Do we need a one? Are there critical bugs we 
fixed? Are there critical bugs blocking the release?


There’s a pull request for icu-config removal that we could apply to 
-base. It might warrant a release.


If the answer is yes, if you can help me by updating the 
(non-autogenerated) pieces of the release notes, that would help me a bit.


If the answer is yes, I would be cutting the release on a weekend.


It would be nice to have a new release of -base, with the v2 ABI changes 
in.  I'm now pretty happy with the v2 ABI on ELF platforms (hopefully 
Windows soon!).


David

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: assertion when using clang + libobjc2

[David Chisnall]

Hi Riccardo,

Thank you for the report.  Most of the tests don’t build with the GCC ABI, so 
that code path is not as well tested as the two newer ABIs - thank you for 
testing it, and please do file bugs if you hit any more issues.  I believe this 
is now fixed in git.

David

> On 30 May 2018, at 18:47, Riccardo Mottola  wrote:
> 
> Hi All,
> 
> I just finished upgrading a Linux/x86 system where I run clang as compiler 
> and David's libobjc2 compiled from our sources. It is gentoo stable, whith 
> clang 5.0
> 
> libobjc2 was compiled with the same clang and from git head.
> 
> After updating libobjc2, any program dies:
> 
>  $ plparse
> plparse: /home/multix/gnustep-cvs/libobjc2/protocol.c:226: BOOL 
> init_protocols(struct objc_protocol_list *): Assertion `aProto->isa == 
> protocol_class_gcc' failed.
> Aborted
> 
> I have recompiled also base, just for safety, but no help.
> 
> 
> any clues?
> Riccardo


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: exceptions pulling an Abort Trap

[David Chisnall]

Hi Riccardo,

This looks like what happens if you have no @catch block anywhere on the stack. 
 If you can recompile the runtime, try sticking #define DEBUG_EXCEPTIONS in 
eh_personality.c - it will report where failures are happening.

David

> On 24 May 2018, at 10:34, Riccardo Mottola  wrote:
> 
> Hi all,
> 
> nobody has a hint?
> 
> I am suspecting that if libobjc2 of FreeBSD was compiled with clang (which 
> surely is) it won't work with GCC. It is very strange I did not find GCC's 
> runtime library though.
> 
> Or maybe the problem is totally different?
> 
> Riccardo
> 
> Riccardo Mottola wrote:
>> Hi,
>> 
>> I have a strange issue on FreeBSD. I am running gnustep git head.
>> 
>> Ít is compiled with gcc7. I  am actually unsure which runtime is being used. 
>> I have libobjc2 installed as a package, I don't know if gnustep picks up 
>> that one or uses gcc's one.
>> 
>> I suppose though yes, this is the ldd of base:
>> 
>> $ ldd /System/Library/Libraries/libgnustep-base.so
>> /System/Library/Libraries/libgnustep-base.so:
>> libobjc.so.4.6 => /usr/local/lib/libobjc.so.4.6 (0x2860)
>> libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x28625000)
>> libavahi-common.so.3 => /usr/local/lib/libavahi-common.so.3 
>> (0x281e1000)
>> libavahi-client.so.3 => /usr/local/lib/libavahi-client.so.3 
>> (0x281ec000)
>> libgnutls.so.30 => /usr/local/lib/libgnutls.so.30 (0x2867d000)
>> libxslt.so.1 => /usr/local/lib/libxslt.so.1 (0x287b6000)
>> libxml2.so.2 => /usr/local/lib/libxml2.so.2 (0x28d88000)
>> libz.so.6 => /lib/libz.so.6 (0x28edb000)
>> liblzma.so.5 => /usr/lib/liblzma.so.5 (0x28ef1000)
>> libm.so.5 => /lib/libm.so.5 (0x28f17000)
>> libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x28f3f000)
>> libffi.so.6 => /usr/local/lib/libffi.so.6 (0x287eb000)
>> libkvm.so.7 => /lib/libkvm.so.7 (0x287f2000)
>> librt.so.1 => /usr/lib/librt.so.1 (0x281fa000)
>> libthr.so.3 => /lib/libthr.so.3 (0x29034000)
>> libicui18n.so.61 => /usr/local/lib/libicui18n.so.61 (0x29057000)
>> libicuuc.so.61 => /usr/local/lib/libicuuc.so.61 (0x29313000)
>> libicudata.so.61 => /usr/local/lib/libicudata.so.61 (0x294ae000)
>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x294b)
>> libc.so.7 => /lib/libc.so.7 (0x28071000)
>> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x294bc000)
>> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x294d5000)
>> libdbus-1.so.3 => /usr/local/lib/libdbus-1.so.3 (0x294de000)
>> libp11-kit.so.0 => /usr/local/lib/libp11-kit.so.0 (0x2951f000)
>> libunistring.so.2 => /usr/local/lib/libunistring.so.2 (0x295f)
>> libtasn1.so.6 => /usr/local/lib/libtasn1.so.6 (0x2977a000)
>> libnettle.so.6 => /usr/local/lib/libnettle.so.6 (0x2978b000)
>> libhogweed.so.4 => /usr/local/lib/libhogweed.so.4 (0x297be000)
>> libidn2.so.0 => /usr/local/lib/libidn2.so.0 (0x297eb000)
>> libelf.so.2 => /lib/libelf.so.2 (0x29807000)
>> libc++.so.1 => /usr/lib/libc++.so.1 (0x2981d000)
>> libexecinfo.so.1 => /usr/lib/libexecinfo.so.1 (0x298db000)
>> 
>> 
>> now, applications are unstable, the get abort trap often and I think this is 
>> everytime an exception occours. This is the stacktrace of an examplle, but  
>> it is always with raise/throg.
>> 
>> Program received signal SIGABRT, Aborted.
>> 0x2823a42f in thr_kill () from /lib/libc.so.7
>> 
>> (gdb) bt
>> #0  0x2823a42f in thr_kill () from /lib/libc.so.7
>> #1  0x2823a40b in raise () from /lib/libc.so.7
>> #2  0x2823a36f in abort () from /lib/libc.so.7
>> #3  0x2812237f in objc_exception_throw () from /usr/local/lib/libobjc.so.4.6
>> #4  0x28d55fcd in -[NSException raise] (self=0x2a262fe4, _cmd=0x2810d1e8 
>> <_OBJC_SELECTOR_TABLE+872>) at NSException.m:1511
>> #5  0x280e90e7 in -[DBSoap login] (self=, _cmd=> out>, url=, userName=,
>> password=, useHttps=) at DBSoap.m:1262
>> #6  0x0804c786 in -[AppController doLogin:] (self=, 
>> _cmd=, sender=) at AppController.m:295
>> #7  0x284d3878 in -[NSApplication sendAction:to:from:] (self=0x2a0a88c4, 
>> _cmd=0x2358 <_OBJC_SELECTOR_TABLE+664>, aSelector=0x2a1157f8,
>> aTarget=0x2a21c284, sender=0x2a022c84) at NSApplication.m:2250
>> #8  0x28530e3e in -[NSControl sendAction:to:] (self=0x2a022c84, 
>> _cmd=0x28876238 <_OBJC_SELECTOR_TABLE+696>, theAction=0x2a1157f8,
>> theTarget=0x2a21c284) at NSControl.m:760
>> #9  0x2850bde1 in -[NSCell _sendActionFrom:] (self=0x2c483984, 
>> _cmd=0x28876290 <_OBJC_SELECTOR_TABLE+784>, sender=0x2a022c84)
>> at NSCell.m:1451
>> #10 0x28507c43 in -[NSButtonCell performClickWithFrame:inView:] 
>> (self=0x2c483984, _cmd=0x2390 <_OBJC_SELECTOR_TABLE+720>,
>> cellFrame=..., controlView=0x2a022c84) at NSButtonCell.m:1590
>> #11 0x285311bb in -[NSControl performClick:] (self=0x2a022c84, 
>> _cmd=0x28870008 

New ABI changes upstreamed (for ELF)

[David Chisnall]

Hello all,

As of today, the clang changes to support the new ABI are upstream in the LLVM 
repo, so you can specify -fobjc-runtime=gnustep-2.0 and get the new ABI with 
any clang built from the master branch after today.

The new ABI is currently ELF-only (though as I now work at Microsoft Research, 
I have access to Windows machines quite easily, and as Microsoft is shipping 
the runtime I hope to have some time to work on the PE/COFF port quite soon).

The -base changes mostly relate to the new constant string representation.  
Unfortunately, these exposed bugs in the NSString implementations of various 
methods related to unicode, and I then went down a rabbit hole of trying to fix 
these by providing an ICU version.  I don’t know what the correct approach here 
is, but we can’t merge the (fairly simple) changes to support the new constant 
string representation without introducing a number of regressions in the test 
suite.  Help fixing this would be appreciated!

More testing is also very welcome!  The new ABI is *probably* stable now, but 
I’m planning on waiting until the LLVM 7.0 release before making any real 
guarantees about compatibility.  I hope to do the 2.0 release of the runtime at 
around the same time as the LLVM 7.0 release.

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: State of new abi

[David Chisnall]

Hi,

Sorry for the delayed response - I was at a workshop last week and was a bit 
behind on email.

On 13 May 2018, at 22:08, Ivan Vučica  wrote:
> 
> Hi,
> 
> to confirm, is current libobjc2 master incompatible with current gnustep-base 
> master?
> 
> Stjepan has been building GNUstep using the following instructions:
>   http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
> and I remembered that the failure could be due to the development of the new 
> abi.

This is a bug in libobjc2, which I have now fixed.  I forgot that objc_slot was 
part of the public API and so renamed it to objc_slot_v1, which then broke 
things.  I have now reverted its name to objc_slot and introduced a new 
objc_slot2, which fixes the issue.

> I powered on the laptop during my vacation, took a quick look, and told him 
> to git checkout 1.9. This seems to have worked.
> 
> Is this intentional?

No, it was a bug (though the master branch of libobjc2 may contain experimental 
code so may be less reliable than a release).

On a related note, I have had no feedback at all from requests to test the 1.9 
and master branches in preparation for the 1.9 and 2.0 releases.

> Presumably -base newabi branch is not ready to be merged yet — but should 
> libobjc2’s master branch be using the new abi then?

I have some other changes in the -base newabi branch.  It’s probably fine to 
merge the changes so support the support for the new NSConstantString parts, 
but unfortunately the new constant string exposes some bugs in -base’s unicode 
handling (in particular, incompatibilities with NSString and GSString), which 
are probably exposed by other NSString subclasses.

> I think that’s fine, apart from breaking scripts that build GS from head. 
> Travis CI is also erroring out:
>   https://travis-ci.org/gnustep/libs-base

The -base Travis script should be building libobjc2 without tests.  The 
libobjc2 Travis script builds it with tests and runs them.

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: -make option to specify runtime?

[David Chisnall]

On 4 May 2018, at 10:42, Stjepan Brkić  wrote:
> 
>> Hello the list,
>> 
>> For testing the runtime’s 2.0 ABI, I am patching my post-install Makefiles 
>> to set -fobjc-runtime=2.0 instead of whatever the default is (1.7?). Please 
>> can someone who understands how -make works add a configure-time option so 
>> that you can specify the runtime version?
>> 
>> David
> 
> This sounds like a good introductory task for GSoC.
> Would you mind if I took this one?

Go ahead.  I have a mild allergic reaction to GNU Make and autoconf, so help is 
very much appreciated!

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

-make option to specify runtime?

[David Chisnall]

Hello the list,

For testing the runtime’s 2.0 ABI, I am patching my post-install Makefiles to 
set -fobjc-runtime=2.0 instead of whatever the default is (1.7?).  Please can 
someone who understands how -make works add a configure-time option so that you 
can specify the runtime version?

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Tentative Objective-C Runtime Release Plan

[David Chisnall]

Hello,

It has been a very long time since the 1.8 release of the runtime and there 
have been a lot of changes.  My current plan is to do a 1.9 release soon, 
shortly followed by a 2.0 release.

The 1.9 release wraps up all of the bug fixes and performance improvements from 
the last couple of years.

The 2.0 release is a much larger change.  It introduces the new ABI and moves 
to using the new ABI for its internal data structures (dynamically updating 
older ABI structures on load).  The new ABI is designed for forward 
compatibility, making it comparatively easy to extend any of the introspection 
structures in future versions.

I have submitted an initial cut at compiler support for clang for review:

https://reviews.llvm.org/D46052

I would encourage everyone to grab the experimental clang and libobjc2 trees 
and try compiling with -fobjc-runtime=gnustep-2.0:

https://github.com/davidchisnall/clang-gnustep-abi-2
https://github.com/davidchisnall/libobjc2

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Segmentation Faults - OpenBSD

[David Chisnall]

On 13 Apr 2018, at 00:31, Riccardo Mottola  wrote:
> 
> Hi,
> 
> Richard just commited some promising fixes.
> 
> Things seem better, but not stable. Here a summary of the current status. 
> OpenBSD seems fine on x86, on amd64 I get some strange issues that might not 
> be related
> 
> FreeBSD/amd64/clang
> - seems to work with all apps I tried
> - One test failure:
> base/NSException/basic.m:
> Failed test: basic.m:51 ... addresses and symbols match

This test appears to expect the system backtrace_symbols function to demangle 
Objective-C method names.  It should probably be changed to a hope rather than 
an excepted behaviour, because I’ve never seen it pass.

> OpenBSD/i386/gcc
> - seems to work fine
> - Two test failures
> base/NSException/basic.m:
> Failed test: basic.m:51 ... addresses and symbols match
> base/NSProcessInfo/general.m:
> Failed test: general.m:48 ... -systemUptime works

This one probably needs some per-platform plumbing.

> 
> 
> OpenBSD/amd64/gcc
> - gui apps do not start due to some symbol relocations maybe a spurious error
> - Two test failures
> base/NSException/basic.m:
> Failed test: basic.m:50 ... call stac addresses is not empty

You may need to link libexecinfo to make this work on OpenBSD (I think we do 
that by default if it’s found, but maybe it wasn’t installed?)

David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Segmentation Faults - OpenBSD

[David Chisnall]

On 10 Apr 2018, at 07:13, Sebastian Reitenbach <sebas...@l00-bugdead-prods.de> 
wrote:
> 
> Hi,
> 
> Am Dienstag, April 10, 2018 00:28 CEST, Riccardo Mottola 
> <riccardo.mott...@libero.it> schrieb: 
> 
>> Hi,
>> 
>> On 2018-04-07 18:04:12 + David Chisnall <gnus...@theravensnest.org> 
>> wrote:
>> 
>>>> No idea if either of them are relevant, but I’ve just pushed two fixes for 
>>>> > memory-related errors in -base.  One writes some data through an > 
>>>> uninitialised pointer when an exception is thrown and the platform doesn’t 
>>>> > provide backtrace.  The other treats things as GSString instances even 
>>>> if > they aren’t and so can potentially dereference an invalid pointer.
>>>> Either of these could cause random crashes in some usage on some platforms.
>> 
>> 
>> unfortunatley not. I still get a hard crash while running "plmerge". For me 
>> it is OpenBSD only, but I got that Gregory has issues on linux to.
>> 
>> I was able to compile with debug and get a better starcktrace, although I 
>> think it is corrupted and loops.. or we have some case of /thread recurision
> 
> while debugging GNUMail, I also tried gnustep-base from git, and I saw the 
> very same backtrace, when I tried to rebuild gnustep-gui afterward. 
> Threre I saw it happen in make_services.

This looks like the bug with non-fragile ivars appearing to have different 
offsets in different libraries.  If I give you a clang patch, are you able to 
test it?

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New ABI NSConstantString

[David Chisnall]

On 8 Apr 2018, at 16:27, Richard Frith-Macdonald 
 wrote:

>> I also note that a lot of the NSString method implementations are not well 
>> optimised.
> 
> Yes ... because they are almost never used as we historically had unicode 
> string methods and latin1 string methods.  I did optimise the more 
> 'importent' (ie ones causing trouble in the test applications I tried) ones 
> though.

It probably depends a lot on the application.  A number of things I’ve written 
have used custom NSString subclasses to keep the data in some other format for 
interoperability with some other library.  Language bridges also typically come 
with custom NSString subclasses that wrap the native string representation.  In 
these cases, the NSString implementations are used all of the time.

>> In a number of places, -characterAtIndex: is called repeatedly, when 
>> -getCharacters:range: is normally significantly more efficient.
> 
> You have to be very careful about using -getCharacters:range: to give more 
> efficiency, and also worry about extra complexity to put buffers on stack or 
> heap (or work in subsections of strings copied to a stack buffer etc).  I 
> remember quite a few cases where more complex code 'optimised' to work that 
> way turned out to be slower for common cases.

In Étoilé, we had some macros for iterating over all characters in a string 
using -getCharacters:range:.  In Objective-C++ it’s also quite easy to write a 
wrapper that you can use with C++11 range-based for loops to iterate over 
unichars in an NSString (I’ve not done this for NSString, but I have for 
NSIndexSet, which provides a similar interface).

In the newabi branch, I’ve modified NSString to use an on-stack buffer and 
repeated calls to -getCharacters:range: in a loop, rather than copying the 
entire string to hash:

https://github.com/gnustep/libs-base/commit/ad00cd640d69e54d730879d3d16d687da9c70c14

I don’t have any good applications to profile, but I’d be interested to know if 
cherry picking this change to master makes things better or worse for you (or 
makes no difference - in which case it’s probably worth keeping because at 
least it will reduce lock contention on the memory allocator and memory usage).

>> The ICU UText interface provides something very similar to 
>> -getCharacters:range: as its primitive method (a callback that fills a 
>> buffer with UTF-16 characters) and has some carefully optimised routines.
> 
> Yes, I have been thinking about implementing an ICU subclass of NSString (on 
> platforms where ICU is available) for some time.  My assumption/hope is that 
> it might be both more correct (in odd parts of unicode that people writing 
> our stuff have been unaware of) and faster than our UTF16 code.  Even if 
> performance tturned out to be poor, it would be good to have a reference 
> implementation for testing for correctness.

GSICUString ought to provide a basis for this.  I’ve cleaned up a bit of the 
code in the newabi branch and added a -rangeOfComposedCharacterSequenceAtIndex: 
to NSString that constructs an on-stack UText (with an on-stack buffer) and 
uses ICU’s break iterator to find character breaks:

https://github.com/gnustep/libs-base/commit/5a896fbaea915f4b49da5077ae15bfeaec7df032

Its behaviour appears to match Apple’s and most of the tests fail, but a bunch 
of the NSURLConnection tests are failing in a somewhat opaque way (these tests 
are not really intended for debugging this kind of problem, so they’re really 
just highlighting that we’re lacking some test coverage elsewhere).

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New ABI NSConstantString

[David Chisnall]

On 8 Apr 2018, at 16:19, Fred Kiefer  wrote:
> 
> I think your implementation of characterAtIndex: is wrong for the UTF8 case. 
> Sadly things are more complicated. Please have a look at the (slow) way the 
> old code is handling this.

All of the UTF-8 and UTF-32 cases are placeholders for now.  The compiler 
generates either ASCII or UTF-16.

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: New ABI NSConstantString

[David Chisnall]

On 8 Apr 2018, at 12:41, David Chisnall <gnus...@theravensnest.org> wrote:
> 
> On 8 Apr 2018, at 10:55, Richard Frith-Macdonald 
> <richard.frith-macdon...@theengagehub.com> wrote:
>> 
>> 
>> 
>>> On 6 Apr 2018, at 11:00, David Chisnall <gnus...@theravensnest.org> wrote:
>>> 
>>> It would probably help catch more bugs if we made use of NSString’s 
>>> class-cluster nature more in -base.  I have just fixed a bug in GSString 
>>> where we were checking one object matched a particular class before 
>>> dereferencing the _flags ivar of the other.  I caught this because the 
>>> other was a GSTinyString, which is almost never a valid pointer.
>> 
>> Possibly, but performance *is* an issue here.  The NSString code was 
>> rewritten some years ago (moving away from them use of class cluster 
>> features) as a result of extensive profiling of real-world applications 
>> which were running too slow, precisely because NSString methods are very 
>> heavily used in real apps.  At the time somethjing like 20% of the CPU was 
>> wasted in method dispatch overheads (the -characterAtIndex: method is one of 
>> the cluster primitives and a major culprit) but there were also performance 
>> issues due to buffer allocation and copying of internal representations.  
>> The changes made a substantial improvement in general performance as well as 
>> causing multipler orders of magnitude improvement in a few pathological 
>> cases.
> 
> I agree that we should be improving performance for critical code, but 
> unfortunately it appears that we have done so at the expense of correctness 
> in a number of places.  As per my other email, 
> -rangeOfComposedCharacterSequenceAtIndex: appears to give the wrong results 
> in almost every nontrivial case, and is unfortunately one of the primitive 
> methods for a lot of things.
> 
> I also note that a lot of the NSString method implementations are not well 
> optimised.  In a number of places, -characterAtIndex: is called repeatedly, 
> when -getCharacters:range: is normally significantly more efficient.  The ICU 
> UText interface provides something very similar to -getCharacters:range: as 
> its primitive method (a callback that fills a buffer with UTF-16 characters) 
> and has some carefully optimised routines.

I’ve pushed my WIP changes to the newabi branch - review is welcome!  This 
branch disables the GSString implementation of 
-rangeOfComposedCharacterSequenceAtIndex: and falls back to the NSString one 
(which is also wrong, but now consistently wrong).

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: GSUnicodeString and NSString disagree on rangeOfComposedCharacterSequenceAtIndex:

[David Chisnall]

On 8 Apr 2018, at 09:38, Fred Kiefer <fredkie...@gmx.de> wrote:
> 
> 
> 
>> Am 07.04.2018 um 20:51 schrieb David Chisnall <gnus...@theravensnest.org>:
>> 
>> I am testing out a new version of the compiler / runtime that is producing 
>> NSConstantString instances with UTF-16 data.  I have currently disabled a 
>> lot of the NSConstantString optimisations, on the basis of ‘make it work 
>> then make it fast’ and I’m still seeing quite a lot of test failures.  The 
>> most recent ones seem to come from the fact that GSUnicodeString’s 
>> implementation of rangeOfComposedCharacterSequenceAtIndex: calls 
>> rangeOfSequence_u(), which returns a different range to NSString’s 
>> implementation.
>> 
>> I have ls (an GSUnicodeString) and indianLong (a UTF-16 NSConstantString) 
>> from the NSString/test00.m. If I call -getCharacters:range: on both, then I 
>> get the same set of characters for [indianLong length] characters.  This is 
>> as expected.  When searching for indianLong in ls, it is not found.  
>> Sticking in a lot of debugging code, I eventually tracked it down to this 
>> disagreement and when I comment out GSUnicodeString’s implementation of 
>> rangeOfComposedCharacterSequenceAtIndex: so that it uses the superclass 
>> implementation then this test passes.
>> 
>> Please can someone who understands these bits of exciting unicode logic take 
>> a look and see if there’s any reason for the disagreement?
> 
> I am surely no expert here, but I had a quick look at the code and the two 
> algorithms seem to be very similar. The only difference is the set of code 
> points that the characters get compared to. NSString uses [NSCharacterSet 
> nonBaseCharacterSet], which looks correct to me. On the other hand GSString 
> uses uni_isnonsp(), which I would read as "non spacing“ but is never 
> explained. The code here is as follows: 
> 
> BOOL
> uni_isnonsp(unichar u)
> {
>  /*
>   * Treating upper surrogates as non-spacing is a convenient solution
>   * to a number of issues with UTF-16
>   */
>  if ((u >= 0xdc00) && (u <= 0xdfff))
>return YES;
> 
> // FIXME check is uni_cop good for this
>  if (GSPrivateUniCop(u))
>return YES;
>  else
>return NO;
> }
> 
> As a side effect this should handle the upper surrogates correctly, but not 
> the lower and I have no idea what GSPrivateUniCop does, even after looking at 
> the code various times. OK, it is a binary search on uni_cop_table, but what 
> is in that table?

Thanks.  I co-mentored a GSoC student a couple of years ago working on unicode 
collation and discovered quite how little I understand about unicode. I am 
reminded of that now:

[NSCharacterSet nonBaseCharacterSet] contains the characters in the Mark sets, 
which are mark sets, which appear to be the combining diacritics.  I don’t 
believe that the current code correctly handles other combining sets, such as 
the emoji flag sequences, which are not in the Mark sets.  A simple test 
demonstrates this:

```objc
#import 

int main(void)
{
@autoreleasepool {
uint32_t utf32[] = {0x1F1E7, 0x1F1EA};
NSString *str = [[NSString alloc] initWithBytes: utf32 length: 
sizeof(utf32) encoding: NSUTF32LittleEndianStringEncoding];
NSLog(@"%@, %ld", str, (unsigned long)[str 
rangeOfComposedCharacterSequenceAtIndex: 0].length);
}
}
```

On macOS, this prints a Belgian flag and tells me that it is 4 UTF-16 code 
units long.  On GNUstep for me it prints the flag but tells me that the length 
is 1 with the version from NSString and 2 with the version from GSString.

For NSRegularExpression, I wrote a pair of adaptors classes that allow you to 
expose either the NSString or ICU UText interfaces using the other’s 
representation.  I wonder if we should consider moving to something like that 
on platforms that support ICU?  I’m not sure where the UText interface comes 
from, but it seems to now be increasingly widely used inside ICU and could have 
been designed specifically to support the abstractions that NSString exposes 
(it requires that you be able to access the string as UTF-16 code units and 
works by providing a buffer that is filled using a mechanism very similar to 
-getCharacters:range:).  I have implemented a simple function that uses ICU to 
DTRT:

```objc
NSRange rangeOfComposedCharacterSequenceAtIndex(NSString *str, NSUInteger idx)
{
UText *txt = UTextInitWithNSString(NULL, str);
UErrorCode e = 0;
UBreakIterator *it = ubrk_open(UBRK_CHARACTER, NULL, NULL, 0, );
ubrk_setUText(it, txt, );
if (U_FAILURE(e))
{
NSLog(@"Error handling goes here");
}
ubrk_preceding(it, idx);
uint32_t origin = ubrk_current

Re: GSUnicodeString and NSString disagree on rangeOfComposedCharacterSequenceAtIndex:

[David Chisnall]

On 7 Apr 2018, at 19:51, David Chisnall <gnus...@theravensnest.org> wrote:
> 
> I’m now hitting a failure in the unichar_const tests, because for some reason 
> a GSMutableString and a (UTF-16) NSConstantString are not comparing equal, in 
> spite of having the same hash, the same length, and the same values for both 
> characters...

Ignore that bit - I’d made the same fix in GSMutableString, but hadn’t 
recompiled before testing.  I’m now passing all of the NSString tests, with 
both rangeOfSequence_c and rangeOfSequence_u disabled and the subclasses that 
use it falling back to the superclass implementation.  I don’t know if the 
NSString or the GSString implementation is the correct one, but at least one of 
them is wrong, and the NSString one at least works with other NSString 
subclasses that implement the required primitive methods of NSString.

David


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev