search for: ehfram

...to the SjLj personality would defeat that I think > (it seems to use LLVM-defined internal data structures for storing the > context information, such as the "five word buffer in which the calling > context is saved"). In that case it would be better to immediately > switch to ehframe-based exception handling so as to at least reap some > benefits in the process. > Sounds right. > It is not clear to me from reading > http://llvm.org/docs/ExceptionHandling.html whether it is possible to > use our own setjmp/longjmp infrastructure without modifying LLVM. I'm...

Hi, Does lld support linker relaxation that may shrink code size? As far as I see lld seems to assume that the content of input sections to be fixed other than patching up relocations, but I believe some targets may benefit the extra optimization opportunity with relaxation. Specifically, I'm currently working on adding support for RISC-V in lld, and RISC-V heavily relies on linker relaxation

Hi, In our (non-C) compiler we use setjmp/longjmp to implement exception handling. For the initial implementation LLVM backend, I'm keeping that model. In order to ensure that changes performed in a try/setjmp==0 block survive the longjmp, the changes must be done via volatile operations. Given that volatility is a property of individual load/store instructions rather than of memory slots in

...al branch has been shortened from 18 bytes to 12 bytes due to the other changes. On Tue, Jul 11, 2017 at 1:59 PM, Peter Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello, > > To the best of my knowledge I think the closest analogue is something > like the Synthetic EHFrame and MergeInputSections, not strictly code > relaxation, but these do involve changes in size of sections. > > Can I ask you a quick question? In many architectures not all > pc-relative offsets are exposed to the linker as relocations so it > isn't safe to change the sizes of s...

...> > >> > >> On Tue, Jul 11, 2017 at 1:59 PM, Peter Smith via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hello, >>> >>> To the best of my knowledge I think the closest analogue is something >>> like the Synthetic EHFrame and MergeInputSections, not strictly code >>> relaxation, but these do involve changes in size of sections. >>> >>> Can I ask you a quick question? In many architectures not all >>> pc-relative offsets are exposed to the linker as relocations so it >>>...

...= Target->adjustRelaxExpr(Type, RelocatedAddr, Expr); diff --git a/ELF/Writer.cpp b/ELF/Writer.cpp index 90462ecc7..418133ebd 100644 --- a/ELF/Writer.cpp +++ b/ELF/Writer.cpp @@ -1570,8 +1570,11 @@ template <class ELFT> void Writer<ELFT>::finalizeSections() { applySynthetic({InX::EhFrame}, [](SyntheticSection *SS) { SS->finalizeContents(); }); - for (Symbol *S : Symtab->getSymbols()) + for (Symbol *S : Symtab->getSymbols()) { S->IsPreemptible |= computeIsPreemptible(*S); + if (S->isGnuIFunc() && Config->ZIfuncnoplt) + S-...

...ts at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on using ehframe information, > a (C++-)ABI-compliant personality function, and possibly linking in > parts of its own runtime that depend on this information being correct? > > > I would say that the coupling between LLVM generated code and the HP > unwind interface is pretty low. The on...

Hi all, At the recent LLVM developers' meeting, I presented a lightning talk on an approach to reduce the amount of dead debug data left in an executable following operations such as --gc-sections and duplicate COMDAT removal. In that presentation, I presented some figures based on linking a game that had been built by our downstream clang port and fragmented using the described approach.

...> >>> >>> I think linkers parse .eh_frame partly because they have no other >>> choice. That being said, I think it's format is not too complex, so >>> similarly the parser isn't too complex. You can see LLD's ELF >>> implementation in ELF/EhFrame.cpp, how it is used in ELF/InputSection.cpp >>> (see the bits to do with EhInputSection) and EhFrameSection in >>> ELF/SyntheticSections.h (plus various usages of these two throughout the >>> LLD code). I think the key to any structural changes in the DWARF format to &gt...