[lld] r252790 - Add support for processing .eh_frame.

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 9 16:42:03 PST 2016


Why did you use personality function names instead of SymbolBody pointers
to personality functions? In order to uniquify something by functions,
pointer comparison is faster (and probably more straightforward in the LLD
architecture) than string comparison.

On Mon, Feb 8, 2016 at 1:20 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com
> wrote:

> >> +    uint32_t ID = read32<E>(D.data() + 4);
> >> +    if (ID == 0) {
> >> +      // CIE
> >> +      Cie<ELFT> C(S, Index);
> >> +
> >> +      StringRef Personality;
> >> +      if (HasReloc) {
> >> +        uint32_t SymIndex = RelI->getSymbol(Config->Mips64EL);
> >> +        SymbolBody &Body =
> >> *S->getFile()->getSymbolBody(SymIndex)->repl();
> >> +        Personality = Body.getName();
> >> +      }
> >> +
> >> +      std::pair<StringRef, StringRef> CieInfo(Entry, Personality);
> >
> >
> > So, here, CIEs are uniquified by their contents and some symbol names.
> What
> > is the actual rule? I want to know what it is intended to do for what.
> >
>
> One symbol name: the personality function. The information about a
> frame is split into a fde and a cie. The cie contains information that
> can be shared by multiple fdes. We can unify cie by content, as long
> as we are careful to include which personality function that CIE uses.
>
> See
> https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html
> for the format.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160209/f1f3c6c4/attachment.html>


More information about the llvm-commits mailing list