e3033c0ce5
Prior to this change the clang interface stubs format resembled
something ending with a symbol list like this:
Symbols:
a: { Type: Func }
This was problematic because we didn't actually want a map format and
also because we didn't like that an empty symbol list required
"Symbols: {}". That is to say without the empty {} llvm-ifs would crash
on an empty list.
With this new format it is much more clear which field is the symbol
name, and instead the [] that is used to express an empty symbol vector
is optional, ie:
Symbols:
- { Name: a, Type: Func }
or
Symbols: []
or
Symbols:
This further diverges the format from existing llvm-elftapi. This is a
good thing because although the format originally came from the same
place, they are not the same in any way.
Differential Revision: https://reviews.llvm.org/D76979
20 lines
611 B
C
20 lines
611 B
C
// REQUIRES: x86-registered-target
|
|
// REQUIRES: shell
|
|
|
|
// RUN: mkdir -p %t; cd %t
|
|
// RUN: %clang -target x86_64-unknown-linux-gnu -c -emit-interface-stubs %s -o %t/driver-test3.o
|
|
// RUN: llvm-nm %t/driver-test3.o | FileCheck --check-prefix=CHECK-OBJ %s
|
|
// RUN: cat %t/driver-test3.ifs | FileCheck --check-prefix=CHECK-IFS %s
|
|
|
|
// CHECK-OBJ: bar
|
|
|
|
// CHECK-IFS: --- !experimental-ifs-v2
|
|
// CHECK-IFS-NEXT: IfsVersion:
|
|
// CHECK-IFS-NEXT: Triple:
|
|
// CHECK-IFS-NEXT: ObjectFileFormat:
|
|
// CHECK-IFS-NEXT: Symbols:
|
|
// CHECK-IFS-NEXT: - { Name: "bar", Type: Func }
|
|
// CHECK-IFS-NEXT: ...
|
|
|
|
int bar(int a) { return a; }
|