llvm dev - Jan 2019 - How to link against specific targets? (Porting ShadowCallStack to new PM)

I made a second MachineFunctionPass that can run on new PM and made it
similar to the MachineFunctionPass for legacy PM. It seemed that the
only required analysis used by it was MachineModuleInfo which I also
made a new PM analysis for by separating it into 2 classes: 1 that
holds the meta information specific to a module, and 1 that's the pass
which holds an instance to the first class. The new PM analysis holds
an instance of this first class also. I'm not sure though if there are
new PM equivalents for the addPreserved analyses that
MachineFunctionPass has under it's getAnalysisUsage.

I can't figure out though how to port ShadowCallStack specifically,
assuming I completed all the necessary work for enabling
MachineFunctionPass in new PM, but I imagine that I may have missed a
few things that I didn't account for. I can share what I have
currently if you would like to see.

- Leonard

On Tue, Jan 8, 2019 at 10:37 AM Craig Topper <craig.topper at gmail.com>
wrote:
>
> Isn't ShadowCallStack a MachineFunctionPass? Machine IR doesn't use
the new PM yet.
>
> ~Craig
>
>
> On Tue, Jan 8, 2019 at 10:30 AM Leonard Chan via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> I'm in the process of trying to port ShadowCallStack from the
legacy
>> pass manager to the new one. I ran into an issue though where it seems
>> I cannot link against anything I added in ShadowCallStack.cpp when
>> trying to build c-index-test (via just running ninja check-all). I
>> think the reason for this is because nothing under lib/Target/X86/ is
>> a part of any library compiled with c-index-test (if I'm reading
the
>> CMake correctly). I imagine this would also mean I wouldn't be able
to
>> successfully build other binaries like clang.
>>
>> What I want to know is if there is a proper way to link against code
>> under lib/Target/X86/ (as a part of some shared library or through
>> some other means) such that i could use it with the new pass manager.
>>
>> These are some other thoughts I had attempting to find a possible
solution:
>> - I could not find an instance of classes under lib/Target/X86/ (or
>> any other target for that matter) that are used or exposed by anything
>> outside of lib/Target/
>> - The only things that seem exposed under lib/Target/ are a few files
>> packed into libLLVMTarget.a and none of it is linked against source
>> files under llvm/Target/<TARGET>
>> - If ShadowCallStack is meant to be a pass that should eventually work
>> for any target, at some point it could be pulled out from the X86
>> directory and also be included in libLLVMTarget.a, but I'm not sure
>> how the CMake dependency hierarchy would support this.
>>
>> Thanks,
>> Leonard
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

I think Craig's point was that moving machine passes to the new PM
hasn't
even started. MachineFunctions, MachineModuleInfo, none of it is going to
work.

But you also don't need it to work. `-fexperimental-new-pass-manager` only
enables the new PM for the IR pipeline. The machine passes and all of the
code generator are handled independently.

On Tue, Jan 8, 2019 at 10:52 AM Leonard Chan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I made a second MachineFunctionPass that can run on new PM and made it
> similar to the MachineFunctionPass for legacy PM. It seemed that the
> only required analysis used by it was MachineModuleInfo which I also
> made a new PM analysis for by separating it into 2 classes: 1 that
> holds the meta information specific to a module, and 1 that's the pass
> which holds an instance to the first class. The new PM analysis holds
> an instance of this first class also. I'm not sure though if there are
> new PM equivalents for the addPreserved analyses that
> MachineFunctionPass has under it's getAnalysisUsage.
>
> I can't figure out though how to port ShadowCallStack specifically,
> assuming I completed all the necessary work for enabling
> MachineFunctionPass in new PM, but I imagine that I may have missed a
> few things that I didn't account for. I can share what I have
> currently if you would like to see.
>
> - Leonard
>
> On Tue, Jan 8, 2019 at 10:37 AM Craig Topper <craig.topper at
gmail.com>
> wrote:
> >
> > Isn't ShadowCallStack a MachineFunctionPass? Machine IR
doesn't use the
> new PM yet.
> >
> > ~Craig
> >
> >
> > On Tue, Jan 8, 2019 at 10:30 AM Leonard Chan via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hi all,
> >>
> >> I'm in the process of trying to port ShadowCallStack from the
legacy
> >> pass manager to the new one. I ran into an issue though where it
seems
> >> I cannot link against anything I added in ShadowCallStack.cpp when
> >> trying to build c-index-test (via just running ninja check-all). I
> >> think the reason for this is because nothing under lib/Target/X86/
is
> >> a part of any library compiled with c-index-test (if I'm
reading the
> >> CMake correctly). I imagine this would also mean I wouldn't be
able to
> >> successfully build other binaries like clang.
> >>
> >> What I want to know is if there is a proper way to link against
code
> >> under lib/Target/X86/ (as a part of some shared library or through
> >> some other means) such that i could use it with the new pass
manager.
> >>
> >> These are some other thoughts I had attempting to find a possible
> solution:
> >> - I could not find an instance of classes under lib/Target/X86/
(or
> >> any other target for that matter) that are used or exposed by
anything
> >> outside of lib/Target/
> >> - The only things that seem exposed under lib/Target/ are a few
files
> >> packed into libLLVMTarget.a and none of it is linked against
source
> >> files under llvm/Target/<TARGET>
> >> - If ShadowCallStack is meant to be a pass that should eventually
work
> >> for any target, at some point it could be pulled out from the X86
> >> directory and also be included in libLLVMTarget.a, but I'm not
sure
> >> how the CMake dependency hierarchy would support this.
> >>
> >> Thanks,
> >> Leonard
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190108/eb7e5cbb/attachment.html>

Hmmm. I'm probably underestimating the work, but do you know what
would need to be done in order to support machine passes in the new
PM?

Do you also happen to have any resources on how I could learn more
about the IR pipeline and how the new and legacy PM fit into it, aside
from just reading over the code?

Thanks,
Leonard