similar to: [LLVMdev] Enable debug for MSP430

Hi, All I am trying to implement a llvm backend. But I encountered the following problem when running the backend: "Fatal error: error in backend: WinEH not implemented for this target" This error is triggered by function processFunctionBeforeFrameFinalized() defined in class TargetFrameLowering. Can anyone help? Thanks a lot! Zhiguo [cid:image001.jpg at 01D50970.C9344210]

Hi, In the document: http://llvm.org/docs/WritingAnLLVMBackend.html described example like: SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &TM) { Data16bitsDirective = "\t.half\t"; Data32bitsDirective = "\t.word\t"; Data64bitsDirective = 0; // .xword is only supported by V9. ZeroDirective = "\t.skip\t"; CommentString = "!";

Hi all I have a question about the '-fno-exceptions' option with clang and 'ExceptionsType' on MCAsmInfo. I am looking for a way to avoid generating stack unwinding codes when compiling with the "armv7-none-linux-gnu" triple using clang. I tried the '-fno-exceptions' option in order to do that, but unwinding function symbols like

Hi! My general understanding of the debug symbol support is that: - the backend defines in the XXXMCAsmInfo class if debug information is supported (e.g. SupportsDebugInformation = true / false) - if I don't want to output debug information then I can use the (hidden) command line option -disable-debug-info-print (defined in DwarfDebug.cpp). However, in NVPTXMCAsmInfo.cpp I found: - a

On 2017-04-26 19:56, Eric Christopher wrote: > That's really weird. I'm quite surprised that the entry block was moved > so much later in the function but haven't had a chance to look more at > it. Probably want to take a look and find out where that's happening and > why. From irc, thegameg helped me find the -enable-shrink-wrap=false, which "fixes" this,

I just got this error message from the GNU assembler: Error: alignment too large: 15 assumed Which made me laugh at first. The corresponding input line was: .align 16 Apparently what's going on here is that ".align 16" is ambiguous: on some architectures it means ".balign 16", and on some it means ".p2align 16", which would mean ".balign 65536" if

2010/1/25 Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com>: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed > > Which made me laugh at first. The corresponding input line was: > >        .align  16 > > Apparently what's going on here is that ".align 16" is ambiguous: on > some architectures

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

On Wed, Apr 22, 2020 at 10:34 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Apr 22, 2020 at 9:28 AM Nagaraju Mekala via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: >> > >> > >> > >> > > -----Original Message-----

Hi, I have a function with: attributes #2 = { "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" } Yet when compiling it generates: https://gist.github.com/carlokok/7c3c98d2fd8c966671f40a5ad94f19d3 (Note how it checks fFinalizer before setting up ebp). It also has a: .loc 36 195 7 prologue_end before this happens How can I get llvm to do the frame

On Jun 8, 2009, at 2:42 PM, robert muth wrote: > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> > wrote: >> >> On Jun 7, 2009, at 6:59 AM, robert muth wrote: >> >>> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >>> wrote: >>>> +cl::opt<std::string>

On Tue, Apr 21, 2020 at 6:16 PM Robinson, Paul <paul.robinson at sony.com> wrote: > > > > > -----Original Message----- > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Nagaraju > > Mekala via llvm-dev > > Sent: Tuesday, April 21, 2020 6:04 AM > > To: jh7370.2008 at my.bristol.ac.uk > > Cc: LLVM Developers Mailing List

On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 7, 2009, at 6:59 AM, robert muth wrote: > >> On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> >> wrote: >>> +cl::opt<std::string> FlagJumpTableSection("jumptable-section", >>> +                                          

Joerg, Referring to your patch https://reviews.llvm.org/rL291172. / switch (MAI->getExceptionHandlingType()) {// // case ExceptionHandling::SjLj:// // case ExceptionHandling::DwarfCFI:// // case ExceptionHandling::ARM:// //*isCFIMoveForDebugging = true;*// //*if (MAI->getExceptionHandlingType() != ExceptionHandling::DwarfCFI)*/*/ /**/ break;/*/ // for (auto &F:

Hi, I've run Clang Static Analyzer checker alpha.cplusplus.NewDeleteLeaks over LLVM codebase to detect false-positives and at the same time eliminate memory leaks. The majority of leaks were detected in lib/Target/* and lib/MC/*. In all cases the similar trick was detected as a leak (example from lib/Target/Sparc/MCTargetDesc/SparcMCTargetDesc.cpp) : static MCStreamer

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've

Hello, Everyone. This is just brief description on building llvm-gcc4 with mingw32. It's definitely non error-free and contains many "hacks", which should be eliminated in the future. 1. Prerequisites We're building in the folowing configuration: 1.1 GCC 3.4.5: gcc -v Reading specs from f:/research/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with:

Hello, I run into a problem that llvm can't write the correct ELFHeaderEFlags for hexagonv4. The following patch can fix it. Index: lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp =================================================================== --- lib/Target/Hexagon/MCTargetDesc/HexagonMCTargetDesc.cpp (revision 265917) +++

I am having an issue with MCJIT on the ppc64 machine architecture. The symptom is that for a particular IR function the target machine won't emit neither an object nor an assembly file and subsequent calling the pointer to function results in a segfault. My application generates on the fly several functions with the builder and executes them with the MCJIT engine. I came across this

Hi This patch fixes code generation bug - 586-class CPUs don't support the nopl instruction and some 686-class CPUs don't support it too. I created bug 17792 for that. BTW. I think you should also optimize padding on these CPUs - instead of a stream of 0x90 nops, you should generate variants of "lea (%esi), %esi" instruction like gcc. This patch disables generation of