llvm dev - Mar 2015 - [LLVMdev] New kind of metadata to capture LLVM IR linking structure

Hi David

Thanks for your email.

What's the benefit/purpose of the MDLLVMModule over just having
the
> MDCompileUnits themselves? I would imagine the user cares about which
> source file the problem was in (obtained from the MDCompileUnit), not the
> sequence of BC modules that may've been built into?
>
We envisage it to be useful when an analysis tool built using LLVM needs to
know which MDCompileUnits were part of a particular library that has been
linked in. For instance, we're currently analysing the sandboxing behaviour
within the Chromium web browser, which comprises hundreds of internal
libraries and many external ones. To be able to perform this analysis  we
have to link them all together into a single .bc/.ll file.

Having the module structure allows us to model interactions between
different modules (without manually (and sometimes unreliably) having to
work out which source file corresponds to which library (e.g. libssl,
libpci, libpolicy, librenderer, etc)). It also allows an analysis tool to
support turning on/off output warnings for particular libraries (as they
can lead to a lot of analysis output).

>
>
>>
>> I would be very grateful if someone could review this.
>>
>> Thanks
>>
>> --
>> Khilan Gudka
>> Research Associate
>> Security Group
>> Computer Laboratory
>> University of Cambridge
>> http://www.cl.cam.ac.uk/~kg365/
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150323/f3587f6b/attachment.html>

On Mon, Mar 23, 2015 at 8:15 AM, Khilan Gudka <Khilan.Gudka at
cl.cam.ac.uk>
wrote:
> Hi David
>
> Thanks for your email.
>
> What's the benefit/purpose of the MDLLVMModule over just having the
>> MDCompileUnits themselves? I would imagine the user cares about which
>> source file the problem was in (obtained from the MDCompileUnit), not
the
>> sequence of BC modules that may've been built into?
>>
>
> We envisage it to be useful when an analysis tool built using LLVM needs
> to know which MDCompileUnits were part of a particular library that has
> been linked in. For instance, we're currently analysing the sandboxing
> behaviour within the Chromium web browser, which comprises hundreds of
> internal libraries and many external ones. To be able to perform this
> analysis  we have to link them all together into a single .bc/.ll file.
>
> Having the module structure allows us to model interactions between
> different modules (without manually (and sometimes unreliably) having to
> work out which source file corresponds to which library (e.g. libssl,
> libpci, libpolicy, librenderer, etc)). It also allows an analysis tool to
> support turning on/off output warnings for particular libraries (as they
> can lead to a lot of analysis output).
>
Fair enough - I've no idea/opinion on whether that's the right
abstraction
(other people with more domain knowledge of analysis infrastructure might
chime in with some thoughts).

Practically speaking: would directory paths be sufficient? The
MDCompileUnits already have information about where the source file was.

- David

>
>
>>
>>
>>>
>>> I would be very grateful if someone could review this.
>>>
>>> Thanks
>>>
>>> --
>>> Khilan Gudka
>>> Research Associate
>>> Security Group
>>> Computer Laboratory
>>> University of Cambridge
>>> http://www.cl.cam.ac.uk/~kg365/
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150323/4e1ee30b/attachment.html>

On Mon, Mar 23, 2015 at 9:50 AM David Blaikie <dblaikie at gmail.com>
wrote:
> On Mon, Mar 23, 2015 at 8:15 AM, Khilan Gudka <Khilan.Gudka at
cl.cam.ac.uk>
> wrote:
>
>> Hi David
>>
>> Thanks for your email.
>>
>> What's the benefit/purpose of the MDLLVMModule over just having the
>>> MDCompileUnits themselves? I would imagine the user cares about
which
>>> source file the problem was in (obtained from the MDCompileUnit),
not the
>>> sequence of BC modules that may've been built into?
>>>
>>
>> We envisage it to be useful when an analysis tool built using LLVM
needs
>> to know which MDCompileUnits were part of a particular library that has
>> been linked in. For instance, we're currently analysing the
sandboxing
>> behaviour within the Chromium web browser, which comprises hundreds of
>> internal libraries and many external ones. To be able to perform this
>> analysis  we have to link them all together into a single .bc/.ll file.
>>
>> Having the module structure allows us to model interactions between
>> different modules (without manually (and sometimes unreliably) having
to
>> work out which source file corresponds to which library (e.g. libssl,
>> libpci, libpolicy, librenderer, etc)). It also allows an analysis tool
to
>> support turning on/off output warnings for particular libraries (as
they
>> can lead to a lot of analysis output).
>>
>
> Fair enough - I've no idea/opinion on whether that's the right
abstraction
> (other people with more domain knowledge of analysis infrastructure might
> chime in with some thoughts).
>
> Practically speaking: would directory paths be sufficient? The
> MDCompileUnits already have information about where the source file was.
>
>
I agree, this seems very weird. You have very good source location
information down to directory/file/line/column for individual instructions
in the existing metadata scheme, I'm not sure what this is getting you over
that?

-eric

>
> - David
>
>
>>
>>
>>>
>>>
>>>>
>>>> I would be very grateful if someone could review this.
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> Khilan Gudka
>>>> Research Associate
>>>> Security Group
>>>> Computer Laboratory
>>>> University of Cambridge
>>>> http://www.cl.cam.ac.uk/~kg365/
>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>>>
>>>
>>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150323/df17d21b/attachment.html>