[LLVMdev] New kind of metadata to capture LLVM IR linking structure

[Khilan Gudka]

Another example is libbrowser (from chromium) that includes sources files
from chrome/browser but also chrome/third_party/mozilla_security_manager.

It would be nice to have a way of reliably identifying which compilation
units were part of a library, which is what we were trying to achieve with
MDLLVMModule but if there are better abstractions then am all for that.


--
Khilan Gudka
Research Associate
Security Group
Computer Laboratory
University of Cambridge
http://www.cl.cam.ac.uk/~kg365/

On 23 March 2015 at 17:24, Khilan Gudka <Khilan.Gudka at cl.cam.ac.uk> wrote:

> Yes we did consider using directory paths to identify libraries, however
> there are cases where this doesn't work. For example, chromium builds a
> libcommon which mostly consists of source files from the folder
> chrome/commom/..., but it also contains the
> file components/nacl/common/pnacl_types.cc (although, other files in that
> folder are not part of libcommon).
>
> --
> Khilan Gudka
> Research Associate
> Security Group
> Computer Laboratory
> University of Cambridge
> http://www.cl.cam.ac.uk/~kg365/
>
> On 23 March 2015 at 16:52, Eric Christopher <echristo at gmail.com> wrote:
>
>>
>>
>> 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-commits/attachments/20150323/3ae94a2f/attachment.html>