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

[Khilan Gudka]

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/df48c6ad/attachment.html>