I see what went wrong. Will post a fix shortly.

In D63978#1706764, @JamesNagurne wrote:

In D63978#1706714, @plotfi wrote:

In D63978#1706502, @JamesNagurne wrote:

In D63978#1706448, @plotfi wrote:

In D63978#1706420, @JamesNagurne wrote:

Our team maintains a downstream embedded ARM clang distribution and some tests from this commit have begun to fail for us.
For a number of these tests, there was a REQUIRES: x86-registered-target at the top, which has now been removed. Specifically, externstatic.c, merge-conflict-test.c, object-float.c, and object.c are failing.

object* tests seem to be based on object.cpp, which had the REQUIRES line, and externstatic.c also had that line prior to the change.
I see that @compnerd suggested the removal, but were you certain that these tests would work on clang toolchains for which x86 is not a registered target?

For a failure example, here the output of lit for our toolchain. If you can make sense of it, I'd appreciate input on how we can fix or work around it:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c | <WORKDIR>/arm-llvm/Release/llvm/bin/FileCheck -check-prefix=CHECK-TAPI <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
 <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c:5:16: error: CHECK-TAPI: expected string not found in input
 // CHECK-TAPI: data: { Type: Object, Size: 4 }
                ^
 <stdin>:1:1: note: scanning from here
 --- !experimental-ifs-v1
 ^

And when run without FileCheck, our raw output:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
 --- !experimental-ifs-v1
 IfsVersion: 1.0
 Triple: thumbv7em-ti-none-eabihf
 ObjectFileFormat: ELF
 Symbols:
 ...

I am sorry for this James. I can add back the REQUIRES lines for now and coordinate with you on making sure your downstream bots are not affected again if the REQUIRES are removed again.
By chance are your bots accessible publicly?

Sadly, they are not. It's on our list of things to investigate, but we don't have the resources to do such a thing quite yet.
I'm looking into the 'arm7*' buildbots to see if they are built similar to ours so I am not leaving you entirely without something to look at. However, if it seems to be common knowledge to always include an X86 target, I think I can talk to my team and change up what we do.

These buildbots seem to also do LLVM_TARGETS_TO_BUILD=ARM, and then set the default target triple to a non-x86 triple (the host's)

That could point towards us being in error here. I'll investigate things a little further, and update when I get the chance.
To be clear: this feature should work for any ELF target, correct?

Yes, it is designed to work for all ELF targets but at the moment it is still in an early state. I am on the llvm IRC as zer0_ BTW

I'd love to bounce ideas off of people in IRC, but the big mean IT security guys say no to any sort of chat programs. It's a real shame.
I found the assumption being missed though, so good news!
Our targets assume hidden visibility by default. After scanning your code (and realizing 'interface' is spelled as 'iterface' in a number of places), I noticed it was looking only for externally visible decls. After that, I scanned out changes and found a sneaky '-fvisibility=hidden' in our toolchain options.

By running all of your tests with '-fvisibility=default', our toolchain passes! If you're willing to review/commit the fix upstream, I'm putting up a review presently.

In D63978#1706502, @JamesNagurne wrote:

In D63978#1706448, @plotfi wrote:

In D63978#1706420, @JamesNagurne wrote:

Our team maintains a downstream embedded ARM clang distribution and some tests from this commit have begun to fail for us.
For a number of these tests, there was a REQUIRES: x86-registered-target at the top, which has now been removed. Specifically, externstatic.c, merge-conflict-test.c, object-float.c, and object.c are failing.

object* tests seem to be based on object.cpp, which had the REQUIRES line, and externstatic.c also had that line prior to the change.
I see that @compnerd suggested the removal, but were you certain that these tests would work on clang toolchains for which x86 is not a registered target?

For a failure example, here the output of lit for our toolchain. If you can make sense of it, I'd appreciate input on how we can fix or work around it:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c | <WORKDIR>/arm-llvm/Release/llvm/bin/FileCheck -check-prefix=CHECK-TAPI <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
 <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c:5:16: error: CHECK-TAPI: expected string not found in input
 // CHECK-TAPI: data: { Type: Object, Size: 4 }
                ^
 <stdin>:1:1: note: scanning from here
 --- !experimental-ifs-v1
 ^

And when run without FileCheck, our raw output:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
 --- !experimental-ifs-v1
 IfsVersion: 1.0
 Triple: thumbv7em-ti-none-eabihf
 ObjectFileFormat: ELF
 Symbols:
 ...

I am sorry for this James. I can add back the REQUIRES lines for now and coordinate with you on making sure your downstream bots are not affected again if the REQUIRES are removed again.
By chance are your bots accessible publicly?

Sadly, they are not. It's on our list of things to investigate, but we don't have the resources to do such a thing quite yet.
I'm looking into the 'arm7*' buildbots to see if they are built similar to ours so I am not leaving you entirely without something to look at. However, if it seems to be common knowledge to always include an X86 target, I think I can talk to my team and change up what we do.

These buildbots seem to also do LLVM_TARGETS_TO_BUILD=ARM, and then set the default target triple to a non-x86 triple (the host's)

That could point towards us being in error here. I'll investigate things a little further, and update when I get the chance.
To be clear: this feature should work for any ELF target, correct?

In D63978#1706420, @JamesNagurne wrote:

Our team maintains a downstream embedded ARM clang distribution and some tests from this commit have begun to fail for us.
For a number of these tests, there was a REQUIRES: x86-registered-target at the top, which has now been removed. Specifically, externstatic.c, merge-conflict-test.c, object-float.c, and object.c are failing.

object* tests seem to be based on object.cpp, which had the REQUIRES line, and externstatic.c also had that line prior to the change.
I see that @compnerd suggested the removal, but were you certain that these tests would work on clang toolchains for which x86 is not a registered target?

For a failure example, here the output of lit for our toolchain. If you can make sense of it, I'd appreciate input on how we can fix or work around it:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c | <WORKDIR>/arm-llvm/Release/llvm/bin/FileCheck -check-prefix=CHECK-TAPI <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
 <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c:5:16: error: CHECK-TAPI: expected string not found in input
 // CHECK-TAPI: data: { Type: Object, Size: 4 }
                ^
 <stdin>:1:1: note: scanning from here
 --- !experimental-ifs-v1
 ^

And when run without FileCheck, our raw output:

> <WORKDIR>/arm-llvm/Release/llvm/bin/clang -c -o - -emit-interface-stubs <WORKDIR>/llvm-project/clang/test/InterfaceStubs/object.c
 --- !experimental-ifs-v1
 IfsVersion: 1.0
 Triple: thumbv7em-ti-none-eabihf
 ObjectFileFormat: ELF
 Symbols:
 ...

In D63978#1701864, @tamur wrote:

It seems that with this patch, llvm-ifs starts to depend on yaml2obj, which as far as I know, was only used for testing purposes until now. Is this intended?

Make sure to clang format the new code. I think this looks ok.

addressing cindy and saleem's feedback

s/;/|/g

tests

Adding back -c. Fixing driver for .ifs files

fixed comment.

I think this change might be breaking builds: http://lab.llvm.org:8011/builders/clang-aarch64-linux-build-cache/builds/16888

Nice! Thanks @phosek. I’m fine with a revert. Currently away from keyboard.

Where are your bots?

Ah I get it, because ld64 is tbd-aware the end product is the text. I’m still not sure if I will add any support to lld for something like ifs, things still seem good just using the ifs text format for the intermediate symbol merging.

Adding better wiring up to llvm-ifs

Does this addition mean that llvm-nm should eventually include some support for other text formats like ifs/elfabi etc? I think this could be pretty useful for writing tests, which I assume is part of the motivation here?

In D67255#1660946, @cishida wrote:

bridgeOS hasn't been added to llvm triple yet, so it's fine to exclude it for now.
also I have a patch I'm adding very soon that takes in llvm::triple and does the arch/platform mapping so you won't need to. I'll update this file when it comes out.

In D67209#1660346, @uabelho wrote:

Hi,

I did a minor change to the test case in r371171 since the

;CHECK: bb

checks matched on the line

;ModuleID = '/repo/bb/

in the output instead of the wanted "bb.0:".

I fixed it by reading input from stdin instead of from the file to make the change as small as possible, but perhaps the

;CHECK: bb

lines should be changed to

;CHECK-LABEL: bb.0:

etc instead.

Ping?

addressing @paquette's feedback

More comments.

addressing @paquette's suggestions.

Moving the guts of the candidate walk loop into the reusable MIRVRegNamer.cpp library

Sounds good.

longer flags, no more =

better diag, better test names

adding .data and .rodata to elf sections

In D66029#1648887, @mpaszkowski wrote:

Gentle ping ;)

I would like to ask someone to commit this for me. I don't have commit rights.

• Dropping vestigial ELFSymbols, now I have IFSSymbol.
• addressed @compnerd 's feedback

More version checks

Checking for conflicts in the Ifs header.

Added some better conflict checking tests.

test updates based on feedback

adding another test, to merge objects and funcs of different sizes.

Adding some tests. and added some really basic symbol conflict error checking (no resolution though).