GCC编译器 - 错误或未指定的行为？

Question

当我在objective-c中对类的ivars进行冲突定义时(不是在同一个文件中重新声明类,而是使用diff ivars命名相同的类,编译器不会发出警告或更好的错误.)可以通过相应文件中的适当方法使用多组ivars.例如

Foo.m:

@interface foo {
int a;
}
- (int)method;
@end

@implementation foo

- (int)method {
    return a;
}

@end

Bar.m:

@interface foo {
float baz;
}

@end

@implementation foo (category)
- (float)blah {
    return baz;
}
@end

编译时没有警告或错误.这是故意的吗？这是一个未经检查的错误吗？(对于记录,a和baz实际上是相同的内存位置.)

编辑:对于记录我说的是iPhone OS,我认为它使用与64位MacOS相同的运行时

Answer 1

虽然明显坏了,但代码应该在没有任何警告的情况下编译,因为编译器没有足够的信息来知道如何警告.正确编译时,它仅在64位(这是新的Objective-C ABI的后果,而不是直接来自非脆弱的ivars)中生成完全不同的链接器错误.

如果添加int main() {}到foo.m然后使用命令行编译它gcc -arch x86_64 foo.m -lobjc,链接错误就会消失,因为objc运行时库提供了完成链接所需的空vtable符号.

在编译期间,将每个.m文件视为一个独立的编译单元.当编译器编译.m文件时,它只知道该.m文件中的内容,该.m文件中导入的内容提供的内容,以及 - 如果为其配置了项目 - 在项目的预编译头.

因此,当你在bar.m中说:

@interface foo {
float baz;
}

@end

@implementation foo (category)
- (float)blah {
    return baz;
}
@end
int main() {}

编译器在foo.m中没有声明的概念.生成的代码描述了访问ivar baz的类foo上的类别.如果链接时该类不存在,则会在现在抛出错误,给定foo.m和bar.m并添加上面的main函数,让我们尝试一些不同的编译:

gcc -arch i386 foo.m -lobjc
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

有道理,因为我们没有在foo.m中定义main()函数.64位编译也是如此.

gcc -arch i386 bar.m -lobjc

编译和链接没有警告.要了解原因,请查看生成的符号(删除了大约十几个不相关的符号):

nm -a a.out
00001f52 t -[foo(category) blah]
00000000 A .objc_category_name_foo_category

因此,二进制文件包含一个在类上命名category的类别foo.没有链接错误,因为链接器实际上并未尝试解析类别.它假定foo在运行时解析类别之前,该类会神奇地出现.

您可以使用ivar跟随运行时的类/类别解析:

env OBJC_PRINT_CLASS_SETUP=YES ./a.out 
objc[498]: CONNECT: pending category 'foo (category)'
objc[498]: CONNECT: class 'Object' now connected (root class)
objc[498]: CONNECT: class 'Protocol' now connected
objc[498]: CONNECT: class 'List' now connected

因此,该类别被标记为待定.一旦运行,运行时就会将它连接起来foo!

现在,64位......

gcc -arch x86_64 bar.m -lobjc
Undefined symbols:
  "_OBJC_IVAR_$_foo.baz", referenced from:
      -[foo(category) blah] in ccvX4uIk.o
  "_OBJC_CLASS_$_foo", referenced from:
      l_OBJC_$_CATEGORY_foo_$_category in ccvX4uIk.o
      objc-class-ref-to-foo in ccvX4uIk.o
ld: symbol(s) not found

链接错误是因为现代Objective-C ABI实际上由于各种原因导致为实例变量和类别发出正确的符号,包括添加可以帮助验证程序的元数据(就像在这种情况下那样).

没有编译错误(这是正确的行为)和链接错误是有意义的.现在,如何将两者连接在一起？

在32位的情况下,一切都编译和链接没有错误.因此,我们需要查看符号并在ObjC调试中查看发生了什么:

gcc -arch i386 bar.m foo.m -lobjc
nm -a a.out
00001e0f t -[foo method]
00001dea t -[foo(category) blah]
00000000 A .objc_category_name_foo_category
00003070 S .objc_class_name_foo
env OBJC_PRINT_CLASS_SETUP=YES ./a.out 
objc[530]: CONNECT: attaching category 'foo (category)'
objc[530]: CONNECT: class 'Object' now connected (root class)
objc[530]: CONNECT: class 'Protocol' now connected
objc[530]: CONNECT: class 'List' now connected
objc[530]: CONNECT: class 'foo' now connected (root class)

啊哈!现在有一个类foo,运行时在启动时将类别连接到类.显然,返回baz伊娃的方法将会失败.

但是64位链接器失败了:

gcc -arch x86_64 bar.m foo.m -lobjc
Undefined symbols:
  "_OBJC_IVAR_$_foo.baz", referenced from:
      -[foo(category) blah] in ccBHNqzm.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

通过添加用于实例变量的符号,链接器现在可以捕获已经错误地重新声明类的情况(如@interfacebar.m中所做的那样).