Re: [cfe-users] [cfe-dev] clang does not emit Ivar class name when compiling libobjc2 on Linux (Mac and gcc Linux are OK)

2016-09-15 Thread David Chisnall via cfe-users
As I said on the libobjc2 bug report, please file a clang bug and assign it to 
me.

David

> On 14 Sep 2016, at 20:53, Lobron, David via cfe-dev  
> wrote:
> 
> Hello cfe-users,
> 
> I'm working to get my the libobjc2 Objective-C runtime working on Linux with 
> clang-3.8.0.  I'm running into a problem with a library of mine that does 
> class introspection.  My ObjC code does type introspection by looping through 
> the ivars of an object and calling ivar_getTypeEncoding on each to get the 
> type of the ivar.  When I compile with gcc, the ivar type for non-primitive 
> variables comes through as @"NSString", @"NSDictionary", etc.  This also 
> works with clang on my Mac.  But when I compile with clang on Linux, I only 
> get the @ character.  I verified that the call to class_copyIvarList on Linux 
> does return a list of Ivar objects, but when I call ivar_getTypeEncoding on 
> those objects on Linux, I only get @, rather than the class name.  I've 
> copied my library's ObjC code below.  
> 
> I talked this over with the owners of libobjc2, and we were wondering if 
> there is a flag I can pass to clang to instruct it to emit this class data.  
> I looked at lib/CodeGen/CGObjCGNU.cpp in the clang source tree, but it wasn't 
> immediately clear what flag I could pass here.  It's possible that there's no 
> such flag, and the non-Apple clang simply doesn't emit this data, but I'd be 
> somewhat surprised if Apple had diverged that much.
> 
> Thanks in advance for any help you can give,
> 
> David
> 
> My library's introspection code, with a debug print statement:
> 
> Ivar *ivarList = class_copyIvarList(c, &ivarCount);
> for (i = 0; i < ivarCount; i++) {
>  Ivar ivar = ivarList[i];
>  const char *ivarCname = ivar_getName(ivar);
>  if (ivarCname != 0 && ivarCname[0] != '_') {
> NSString *ivarName = [NSString stringWithUTF8String:ivarCname];
> const char *ivarType = ivar_getTypeEncoding(ivar);
> if (ivarType[0] == '@' && ivarType[1] == '"') {
> NSString *className = [[[NSString alloc] initWithBytes: &ivarType[2]
>  length: strlen(&ivarType[2])-1
> encoding: NSUTF8StringEncoding] autorelease];
> Class c = NSClassFromString(className);
> if (c == nil) {
> NSLog(@"WARNING: unknown class name \"%@\" in declaration of %@", 
> className, [self class]);
> } else {
> NSLog(@"DBG: Deduced class %@ from className %@", c, className);
> 
> With gcc and clang on the Mac, I get messages like this:
> 
> 2016-09-14 19:29:21.950 archiveserver[1015:1015] DBG: Deduced class NSSet 
> from className NSSet
> 2016-09-14 19:29:21.950 archiveserver[1015:1015] DBG: Deduced class NSString 
> from className NSString
> 2016-09-14 19:29:21.950 archiveserver[1015:1015] DBG: Deduced class NSString 
> from className NSString
> 2016-09-14 19:29:21.950 archiveserver[1015:1015] DBG: Deduced class NSString 
> from className NSString
> 2016-09-14 19:29:21.950 archiveserver[1015:1015] DBG: Deduced class 
> NSDictionary from className NSDictionary
> 2016-09-14 19:29:21.950 archiveserver[1015:1015] DBG: Deduced class 
> NSDictionary from className NSDictionary
> 2016-09-14 19:29:21.950 archiveserver[1015:1015] DBG: Deduced class NSArray 
> from className NSArray
> 
> With clang on Linux, nothing is printed, because ivarType[1] is not a double 
> quote, so the second if evaluates to false.
> 
> 
> 
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



smime.p7s
Description: S/MIME cryptographic signature
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users


Re: [cfe-users] [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big

2016-09-27 Thread David Chisnall via cfe-users
On 26 Sep 2016, at 14:33, Perevalov Alexey via llvm-dev 
 wrote:
> 
> Could somebody point me where to solve that problem, is it AST   
> generation stage, or linkage stage or maybe it's not a problem and just LTO 
> could be solution here?

First, please don’t expect the sizes for different runtimes to be the same (or, 
necessarily, to be even very close).  The Mac runtimes have a bit more support 
from the linker for various things.  To ensure that property introspection is 
consistent without this support, the GNUstep runtime IR generation emits 
property definitions in all compilation units and then uniques them later.

We’re currently working on a new ABI for the GNUstep runtime that should 
address the size issues, but until then this looks pretty much what I’d expect.

David

___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users


Re: [cfe-users] [llvm-dev] objc object file generated for gnustep runtime for ELF target is too big

2016-09-28 Thread David Chisnall via cfe-users
On 27 Sep 2016, at 19:00, Perevalov Alexey  wrote:
> 
> in disassembler output and in final binary, but these protocol aren't used in 
> sample. Neither front end nor linker got rid of it.
> You wrote definitions will be unique, but it didn't strip out unnecessary 
> .objc_protocol and depended fields.
> (frankly saying after strip -s I didn't see .objc_protocol, but still find 
> all selector and protocol names in strings output ;)
> 
> And it's look like a bug.

This is a known issue and is unavoidable with the current ABI.  I’m currently 
working on a replacement GNUstep Objective-C ABI that takes advantage of some 
features of linkers that weren’t available when the original GNU Objective-C 
ABI was created, but it’s spare-time (unfunded) work, so is taking a while.  
With the current prototype, there are a lot of space savings but it’s nowhere 
near ready for release.

David

P.S. This thread is being sent to two mailing lists, neither of which is the 
correct one.  For future reference, cfe-dev is the correct list for development 
issues relating to the clang front end.
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users