[llvm-dev] Intermodule Program Analysis

[Ahmad Nouralizadeh Khorrami via llvm-dev]

Thanks, Jakub. Shared lib is OK. But is it possible to analyze multiple
dependent shared libraries, at the same time?
For example, suppose that the main program is calling sth like what follows:

int main(...)
{
    GtkWidget *window;
    ...
    gtk_window_set_default_size(GTK_WINDOW(window), 300, 200);
    ...
}

Suppose that I want to do alias analysis. In other words, I want to know
all pointers pointing to the address of "window". There exists one in the
main binary. There will, probably, be some aliases in the GTK library code
(passed by "gtk_window_set_default_size()" library call). I have to analyze
both binaries (i.e., main and gtk.so) in a single pass. How is it possible?
Regards.

On Sat, 24 Apr 2021 at 01:36, Jakub (Kuba) Kuderski <kubakuderski at gmail.com>
wrote:

> 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/20210424/08897c0c/attachment-0001.html>