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

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190108/331b4ceb/attachment.html>

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