llvm dev - Mar 2016 - LLVM-related research position at University of Cambridge Computer Lab

Hi all,

We are advertising a position for a research assistant / research
associate at the University of Cambridge Computer Lab, working with
LLVM targeting the Loki (http://www.cl.cam.ac.uk/~rdm34/loki/)
architecture. For full details please see
http://www.jobs.cam.ac.uk/job/9756/, though the 'meat' of the advert
is pasted below. The Loki project has been my main focus for a number
of years and we have a great team here at the lab. Robert Mullins is
your best bet for questions about the job, but if you want a more
informal chat about what it's like to work at the lab or about what
interesting challenges there are surrounding LLVM and Loki then please
don't hesitate to contact me directly.

Pasted advert:
http://www.jobs.cam.ac.uk/job/9756/

Research Assistant £25,023 - £28,982 or Research Associate £28,982 - £37,768

Fixed-term: The funds for this post are available until 31 August
2017. Opportunities to extend the post are subject to the availability
of funding.

Applications are invited for a research assistant/associate to join an
ERC funded project exploring low-power many-core processors at the
University of Cambridge. The project has already developed a robust
research infrastructure including simulators, a LLVM-based compiler
and a full hardware-level implementation of a many-core processor. A
128-core test chip is currently in the process of being produced.

The successful candidate will build upon our existing compiler and
libraries for supporting parallel execution. They will explore how
best to automate and optimise existing support for mapping and
compilation. There is also a plan to extend the existing compilation
process with performance and power constraints (much like those
provided during logic synthesis). In addition, work will investigate
higher-level support for parallel programming, e.g. adding OpenCL or
directive-based support.

The role will provide substantial scope for originality and we expect
that the successful candidate will influence the research direction
and the specific activities and experiments undertaken.

This position can be filled by an appropriate candidate at research
assistant or research associate level, depending on relevant
qualifications and experience. Appointment at research associate level
is dependent on having a PhD (or equivalent experience). Where a PhD
has yet to be awarded appointment will initially be made as a research
assistant and amended to research associate when the PhD is awarded.

Ideal candidates will hold, or shortly complete, a PhD in Computer
Science or Engineering and have a strong publication record. They
should also have practical experience with some of the following:
OpenCL, OpenVX, OpenMP, parallel programming models and runtimes, and
thread-to-core mapping techniques. A thorough understanding of
computer architecture, excellent programming skills and working
knowledge of the LLVM compiler infrastructure (or another compiler
such as GCC and a willingness to learn) is essential.

The post is intended to start on the 1 June, although some flexibility
in the start date is possible.

Informal enquiries may be made to Dr. Robert Mullins
(Robert.Mullins at cl.cam.ac.uk).

I want to detect bad casts in C++ code by using the Clang compiler. The
approach is similar to what Caver and TypeSan do but without using the
compiler-rt.

Caver and TypeSan:

https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-lee.pdfhttps://nebelwelt.net/publications/files/16CCS2.pdf

For example if I have the following C++ code snippet where I want to
cast object |b| into object |D|.

|D*obj =static_cast<D*>(b);|

from where (inside Clang, LTO, thinLTO, etc.) can I get the base class
of |D| and the base class of |b|. Is this available in the Clang
compiler or LTO?

Also, if b is an object of a virtual Class (class with inherited or its
own virtual functions) can I get its virtual pointer at compile time by
using the LTO?

I found out that in |CodeGen/CGExpr.cpp| the explicit case
"BaseToDerived" is handled and you can retrieve |TypeSourceInfo| using
the function |getTypeInfoAsWritten()|. It seems that this information is
enough to get the exact type of this cast at compile-time and should
also work for Template programming, as my, understanding is that Clang
should have abstracted the code into, specific types at this point.

Am I wrong here?

Is there any case where the type of the objects used inside the cast not
known at compile time? Can the, 'real' type be hidden behind a pointer?

see also:
http://stackoverflow.com/questions/41104659/llvm-clang-get-cast-type-during-compile-time?sem=2

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/8097614a/attachment.html>

EDIT: I am working with this setup: LLVM +Clang Compiler for C++, Ubuntu
64bit,

I am currently looking for:

 1.

    a way to get the return addresses of virtual function call and non
    virtual C++ methods inside Clang and LLVM and

 2.

    a way to get the candidate addresses where the return address points
    back after each function return was performed.

I have a few questions and hopefully you guys can help me out.

 1.

    The return-addresses of indirect function calls to virtual functions
    (and thus v-tables), are they pointers? If not, what format do they
    have? How are those handled by Clang?

 2.

    Is the return address of a non virtual function in Clang a pointer
    or a hardcoded value?

 3.

    How can I get the return addresses of an indirect call to a virtual
    function using LLVM? Do i have to import them from Clang and make
    them available during LTO?

 4.

    Is thinLTO a better candidate for helping me recuperate this
    information?

 5.

    Does the return address of a function called from an indirect
    call-site always jump back to the next line (instruction) of
    assembly code after the callsite instruction. Are there some
    occurrences where it doesn't? How is this handled in Clang?

see also it here:
https://stackoverflow.com/questions/41019601/recuperate-return-addresses-of-virtual-and-non-virtual-c-methods-with-clang-an
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/e5c71138/attachment.html>