llvm dev - Apr 2021 - Intermodule Program Analysis

So, is static linking the only solution? In some cases, static linking is
difficult!

On Sat, 24 Apr 2021 at 01:16, Jakub (Kuba) Kuderski <kubakuderski at
gmail.com>
wrote:
> I haven't used gllvm with shared objects and don't know the
details. But
> on high-level, I think that even if your build system produces multiple
> binaries/libraries, you should be able to extract bitcode out of each of
> them, and later link it manually. This obviously won't work for
libraries
> that you can't build by yourself.
>
> On Fri, Apr 23, 2021 at 4:40 PM Ahmad Nouralizadeh Khorrami <
> ahmad.llvm at gmail.com> wrote:
>
>> Hi Jakub,
>> Thanks! IIUC, both gllvm and wllvm work on statically linked objects. I
>> mean they work when everything is contained in the linked bitfile.
>> Therefore, probably, they won't solve the problem?!
>> Regards.
>>
>> On Sat, 24 Apr 2021 at 00:43, Jakub (Kuba) Kuderski <
>> kubakuderski at gmail.com> wrote:
>>
>>> Hi Ahmad,
>>>
>>> Maybe gllvm would work for this use case? There was a similar
thread in
>>> 2019:
https://lists.llvm.org/pipermail/llvm-dev/2019-January/129587.html
>>> .
>>>
>>> -Jakub
>>>
>>> On Fri, Apr 23, 2021 at 4:02 PM Ahmad Nouralizadeh Khorrami via
llvm-dev
>>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hi,
>>>> Typical whole program IR level analyses are done by means of
module
>>>> passes. The modules should be linked before the analysis
process.
>>>> In some rare cases, the analysis needs to be performed across
the whole
>>>> user level code. In other words, suppose that the bitcode files
for the
>>>> program and all shared libraries are available. Also, suppose
that the
>>>> libraries can not be linked, statically. Is it possible to run
an analysis
>>>> (e.g., taint analysis or constant propagation) on the whole
user level
>>>> software stack (at the IR level)? If not, is there any better
approach?
>>>> Regards.
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>>
>>> --
>>> Jakub Kuderski
>>>
>>
>
> --
> Jakub Kuderski
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210424/103f69c3/attachment.html>

Hi Ahmad,

I just tried a toy shared library example and it seems to work fine.

$ cat test_lib.c


int foo(int a, int b) { return a * b; }

$ cat CMakeLists.txt
project(Ahmad)

add_library(ahmad SHARED test_lib.c)

$ mkdir gbuild && cd gbuild
$ cmake .. -GNinja -DCMAKE_C_COMPILER=$(readlink -f ~/go/bin/gclang)
$ ninja
$ ~/go/bin/get-bc libahmad.so
$ llvm-dis-11 libahmad.so.bc -o=-
; ModuleID = 'libahmad.so.bc'
source_filename = "llvm-link"
target datalayout
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"

; Function Attrs: noinline nounwind optnone uwtable
define i32 @foo(i32 %0, i32 %1) #0 {
  %3 = alloca i32, align 4
  %4 = alloca i32, align 4
  store i32 %0, i32* %3, align 4
  store i32 %1, i32* %4, align 4
  %5 = load i32, i32* %3, align 4
  %6 = load i32, i32* %4, align 4
  %7 = mul nsw i32 %5, %6
  ret i32 %7
}
...

-Jakub


On Fri, Apr 23, 2021 at 4:55 PM Ahmad Nouralizadeh Khorrami <
ahmad.llvm at gmail.com> wrote:
> So, is static linking the only solution? In some cases, static linking is
> difficult!
>
> On Sat, 24 Apr 2021 at 01:16, Jakub (Kuba) Kuderski <
> kubakuderski at gmail.com> wrote:
>
>> I haven't used gllvm with shared objects and don't know the
details. But
>> on high-level, I think that even if your build system produces multiple
>> binaries/libraries, you should be able to extract bitcode out of each
of
>> them, and later link it manually. This obviously won't work for
libraries
>> that you can't build by yourself.
>>
>> On Fri, Apr 23, 2021 at 4:40 PM Ahmad Nouralizadeh Khorrami <
>> ahmad.llvm at gmail.com> wrote:
>>
>>> Hi Jakub,
>>> Thanks! IIUC, both gllvm and wllvm work on statically linked
objects. I
>>> mean they work when everything is contained in the linked bitfile.
>>> Therefore, probably, they won't solve the problem?!
>>> Regards.
>>>
>>> On Sat, 24 Apr 2021 at 00:43, Jakub (Kuba) Kuderski <
>>> kubakuderski at gmail.com> wrote:
>>>
>>>> Hi Ahmad,
>>>>
>>>> Maybe gllvm would work for this use case? There was a similar
thread in
>>>> 2019:
>>>>
https://lists.llvm.org/pipermail/llvm-dev/2019-January/129587.html.
>>>>
>>>> -Jakub
>>>>
>>>> On Fri, Apr 23, 2021 at 4:02 PM Ahmad Nouralizadeh Khorrami via
>>>> llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hi,
>>>>> Typical whole program IR level analyses are done by means
of module
>>>>> passes. The modules should be linked before the analysis
process.
>>>>> In some rare cases, the analysis needs to be performed
across the
>>>>> whole user level code. In other words, suppose that the
bitcode files for
>>>>> the program and all shared libraries are available. Also,
suppose that the
>>>>> libraries can not be linked, statically. Is it possible to
run an analysis
>>>>> (e.g., taint analysis or constant propagation) on the whole
user level
>>>>> software stack (at the IR level)? If not, is there any
better approach?
>>>>> Regards.
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Jakub Kuderski
>>>>
>>>
>>
>> --
>> Jakub Kuderski
>>
>
-- 
Jakub Kuderski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210423/7b7677e6/attachment.html>