llvm dev - Jun 2012 - [LLVMdev] What's the difference between using llvm-link and using llvm gold plugin?

Hi,

I'm sorry if the question doesn't fit this mailing list. It seems that
LLVM
does not have a user support mailing list so I post it here.

We're using the LLVM tool chain as our static analysis infrastructure. So,
basically we use LLVM to generate an aggregated .bc file and analyze the
.bc file.

The question I want to ask is what's the difference between using the LLVM
gold plugin to generate the .bc file and using llvm-link?

Previously, we use gold plugin which is quite handy. However, for some
special code base, we can only get a bunch of small .bc file, each of which
corresponding to a C or CPP file. So I'm thinking to use llvm-link to link
them together into one big .bc file. Here comes this question.

Thanks a lot for the help!

Best regards,
Tianyin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120626/7c3ef6e7/attachment.html>

On 26 June 2012 16:46, Tianyin Xu <tixu at cs.ucsd.edu>
wrote:
> Hi,
>
> I'm sorry if the question doesn't fit this mailing list. It seems
that LLVM
> does not have a user support mailing list so I post it here.
>
> We're using the LLVM tool chain as our static analysis infrastructure.
So,
> basically we use LLVM to generate an aggregated .bc file and analyze the
.bc
> file.
>
> The question I want to ask is what's the difference between using the
LLVM
> gold plugin to generate the .bc file and using llvm-link?
>
> Previously, we use gold plugin which is quite handy. However, for some
> special code base, we can only get a bunch of small .bc file, each of which
> corresponding to a C or CPP file. So I'm thinking to use llvm-link to
link
> them together into one big .bc file. Here comes this question.
Gold is a full linker, so it is able to do things llvm-link is not,
like reading ELF files and archives. Being a full linker, it is also
able to create a list of symbols that are needed and pass that to
llvm's internalize pass.
> Thanks a lot for the help!
>
> Best regards,
> Tianyin

Cheers,
Rafael

Hi, Rafael,

Thanks a lot for the explanation!

Could you explain a bit more (sorry I'm not from a compiler background)?
So, what's the difference in the analysis perspective? What does
"reading
ELF files and archives" and "creating a list of symbols passed to
llvm's
internalize pass" do?

I checked a little bit the corresponding .ll file generated according to
the .bc file. It seems that symbols like struct and function names are
preserved. What is missing here? Is it possible for you to give an simple
example?

Thanks a lot!
Tianyin


On Tue, Jun 26, 2012 at 3:04 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> On 26 June 2012 16:46, Tianyin Xu <tixu at cs.ucsd.edu> wrote:
> > Hi,
> >
> > I'm sorry if the question doesn't fit this mailing list. It
seems that
> LLVM
> > does not have a user support mailing list so I post it here.
> >
> > We're using the LLVM tool chain as our static analysis
infrastructure.
> So,
> > basically we use LLVM to generate an aggregated .bc file and analyze
the
> .bc
> > file.
> >
> > The question I want to ask is what's the difference between using
the
> LLVM
> > gold plugin to generate the .bc file and using llvm-link?
> >
> > Previously, we use gold plugin which is quite handy. However, for some
> > special code base, we can only get a bunch of small .bc file, each of
> which
> > corresponding to a C or CPP file. So I'm thinking to use llvm-link
to
> link
> > them together into one big .bc file. Here comes this question.
>
> Gold is a full linker, so it is able to do things llvm-link is not,
> like reading ELF files and archives. Being a full linker, it is also
> able to create a list of symbols that are needed and pass that to
> llvm's internalize pass.
>
> > Thanks a lot for the help!
> >
> > Best regards,
> > Tianyin
>
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120626/4a6341a2/attachment.html>