[PATCH] D71219: Fix conflict value for metadata "Objective-C Garbage Collection" in the mix of swift and Objective-C bitcode

Steven Wu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 25 11:05:54 PST 2020


steven_wu added a comment.

In D71219#1890444 <https://reviews.llvm.org/D71219#1890444>, @jinlin wrote:

> In D71219#1791936 <https://reviews.llvm.org/D71219#1791936>, @steven_wu wrote:
>
> > > 
> > > 
> > > 1. I will add a  llvm-link tests for combining objc and swift bitcode.
> > > 2. What do you mean by "codegen tests for correct value in the object file"? There is no "object file" in the picture. Are you asking for a test that checks the value in the output of llvm-link?
> >
> > I think the decision was to break apart the current "Objective-C Garbage Collection" metadata. You need codegen test to test that OBJC_IMAGE_INFO is generated correctly after breaking apart the value.
>
>
> I have question regarding this. Let's assume we have one assembly file from Objective-C and another one from Swift.
>
> Objective-C assembly:
> L_OBJC_IMAGE_INFO:
>
>   	.long	0
>   	.long	64
>
>
> Swift assembly:
>
> L_OBJC_IMAGE_INFO:
>
>   	.long	0
>   	.long	83953472
>
>
> Let's assume that the llvm-link can link Swift bitcode and Objective-C bit successfully and the llc can generate the assembly for the merged output bitcode.
>
> In the final assembly file, what value do you expect for L_OBJC_IMAGE_INFO?


You can easily test that out with ld64. It depends on the bits in the current garbage collection fields. Most of the fields are useless now (only there for GC which is obsoleted), that is why the module flag uses `Override`. Some bits in there are taking `Max`, like `OBJC_IMAGE_HAS_CATEGORY_CLASS_PROPERTIES`. Swift version should be taking `Error` since mismatch is a failure, unless it is not set.

If you are breaking the module flag "Objective-C Garbage Collection" into all the corresponding bits, you can correctly specify all the right behavior for the bitfield.

> 
> 
>> 
>> 
>>> 3. Let us keep the auto upgrade to a different future diff to keep each diff self contained. Is that ok?
>> 
>> I disagree with that. That is leaving a gap for incompatible bitcode.
>> 
>> Steven




CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71219/new/

https://reviews.llvm.org/D71219





More information about the llvm-commits mailing list