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

[Tianyin Xu]

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>