[PATCH] D76252: [lld-macho] Add basic support for linking against dylibs

Wed Mar 18 03:46:16 PDT 2020

ruiu added a comment.

In D76252#1928528 <https://reviews.llvm.org/D76252#1928528>, @grimar wrote:

> In D76252#1928449 <https://reviews.llvm.org/D76252#1928449>, @ruiu wrote:
>
> > In D76252#1928398 <https://reviews.llvm.org/D76252#1928398>, @jhenderson wrote:
> >
> > > In D76252#1926005 <https://reviews.llvm.org/D76252#1926005>, @ruiu wrote:
> > >
> > > > As to the tests, we generally don't use yaml2obj to write tests (except for COFF which is historically using yaml2obj). If you are using yaml2obj just until lld itself is able to produce files used by tests, I don't think you have to spend too much time writing tests in yaml2obj. Instead, you can submit binary files for now and then replace them later.
> > >
> > >
> > > Hi @ruiu,
> > >
> > > I'm just doing a quick drive by comment here, since I'm not really doing much LLD work at the moment myself. Why are you opposed to yaml2obj being used to generate test inputs instead of llvm-mc? Surely yaml2obj gives more direct control over what is actually in the input? In llvm-mc you only have relatively limited control over some things like relocations.
> > >
> > > It seems to me like yaml2obj is a better instrument to be using for the vast majority of test cases, with only a limited set using llvm-mc as a catch-all test to make sure that we don't miss some odd interaction. Of course, this is all making the assumption that mach-o yaml2obj is straightforward to use (I have a feeling it might not be).
> >
> >
> > You can write tests with yaml2obj too, but if you take a look at ELF, don't you think that we can write fine-grained test cases with llvm-mc too? I want tests to be realistic input files, and in that respect, test cases written in llvm-mc are better than ones in obj2yaml.
> >
> > I also found that tests written in llvm-mc are easier to maintain. For example, imagine that you already have a test file containing tests for relocations and you want to add a new type of relocation. Then, you'll have to not only add a new relocation to a yaml file but also add a few extra bytes with some addend at a right bit-wise position to the .text section, which isn't easy to do by hand. So, I guess you'll end up writing a test in assembly, compile it and then convert it to yaml -- but if that's the case, we should write tests in assembly in the first place. On the other hand, I didn't find a test case that is easy to write in yaml but not in assembly. There might be some, but that shouldn't be too many. So it looks to me that llvm-mc is a better choice to write test files.
>
>
> I think there is no universal approach and I agree with both of you. For example, for testing relocation relaxations I'd definetely prefer using YAML because it is important to get the particular op-codes and relocations in the inputs.
>  It is probaly easier to use YAMLs rather than using llvm-mc and verifying inputs with objdump or alike. For many other things, using llvm-mc is probably a bit more natural.
>
> What I do not agree with is that commiting binaries is OK. From my one last experience after working on
>  yaml2obj and converting LLVM binaries, I found them are source of all kind of problems. If we can use yaml2obj for that out of box, I think we should.
>  If we can't then probably it is OK to use binaries temporary, but probably a bug should be reported about lacking features of yaml2obj and the
>  test should have a FIXME comment with a link.

I think that we are on the same page. I'm not recommending submitting binary files as a permanent measure. What I'm saying is that if a test file can eventually be produced by mach-o lld itself, then we should allow binary files as a temporary measure. For example, it is okay to submit a shared object file as a binary file as a temporary measure until lld is able to produce a shared library file.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76252