similar to: [LLVMdev] LLVM creates unterminated ELF .eh_frame sections

> The problem with this is that __register_frame function (in libgcc_s.so), > registering .eh_frame with an exception handler, only takes the pointer to > .eh_frame, and not the size of data, and should be able to detect the end of > data by scanning it and hitting zero DWORD (size). There is no trailing > zero, and it runs into the next section and tries to interpret it as an >

On 04/30/2013 11:53, Rafael Espíndola wrote: > Are you trying MCJIT?:-) No. > > I first tried to compensate for that in MCJIT by adding those 4 bytes. > That works for Linux, but not for OS X where __register_frame takes a > single FDE at a time. I have an incomplete wip patch if you are > interested. On BSD __register_frame also takes a single argument and therefore needs

I dug into this. Based on the .s files in bugzilla, the latest gcc is now adding dwarf unwind info to describe the function epilog. If you run dwarfdump --eh-frame on the .o files made with the new compiler, you'll see extra dwarf unwind instructions at the end like: ... DW_CFA_advance_loc4 (64) #<-- advance to near end of function

On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On 01 Sep 2010, at 08:47, Talin wrote: > > > Once again, I have no idea what this means or how to go about > > debugging it. > > This is my biggest frustration with DIFactory - there's absolutely > > no way to > > verify that the DWARF debugging information that

On Wed, Sep 1, 2010 at 8:31 AM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > >> >> On 01 Sep 2010, at 08:47, Talin wrote: >> >> > Once again, I have no idea what this means or how to go about >> > debugging it. >> > This is my biggest frustration with

I thought of another work around. The FSF gcc driver can implicitly add -no_compact_unwind to the link line. This tells the linker to not produce compact unwind information from the dwarf unwind info in .o files. Then at runtime the darwin unwinder will fallback and use the slow dwarf unwind info. -Nick On Sep 18, 2009, at 2:27 PM, Nick Kledzik wrote: > I dug into this. Based on

I hate to be a nag, but after several days of working on this I am still utterly stumped. Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause. Based on the advice in the

Hello, I am not able to solve this problem on my own. I have a nested Div tag like this: <div id="training" > <div id="daytraining" >Training </div> </div> Some other elements should insert content here by: <%= content_tag("div" ,"Training",:id => "#{training.date.day}" , :onmouseover =>

An embedded and charset-unspecified text was scrubbed... Name: patch-verifier.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100611/ac456430/attachment.ksh>

Hi, Using latest cvs. A comment-line begins with semicolon ; However - if the line contains ;-- or like this ; -- blabla bla -- You get this error and * stops reading that file: Feb 21 13:47:12 WARNING[17393]: config.c:664 config_text_file_load: Unterminated comment detected beginning on line 0 Shouldn't Asterisk skip any line beginning with a semicolon? Or should a comment now be

On Thu, Mar 17, 2016 at 6:58 PM, Martin Michlmayr <tbm at hpe.com> wrote: > Package: xen > Version: 4.6.0-1+nmu2 > Severity: serious > > This package fails to build in unstable: > >> sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux > ... >> mkdir -p compat >> grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' public/grant_table.h | \

I have a line like the following in my Rails view/template (generating JavaScript): <script type="text/javascript"> ... y = escape(''<%= h(e.error_desc) %>''); ... </script> Because some of the error_descs have newlines, the browser is receiving page code that looks like this: y = escape(''Information about the error. Another line in the

Hi, I had similar problems with EH in ELF in RTDyldMemoryManager::registerEHFrames() calling __register_frame(). I'm not sure these problems are related to this problem since your crash happens in RuntimeDyldMachO::registerEHFrames() in its own processFDE (there are two functions named processFDE(), one in RuntimeDyldMachO.cpp and one in RTDyldMemoryManager.cpp) *before*

On x86_64-linux (ubuntu 8.04), we now have 3 test fails. This happened as of revision 61765 (see http://google1.osuosl.org:8011/builders/llvm-x86_64-linux/builds/1316). The failure mode is: Failed with unknown error (or has stderr output) at line 1 /usr/bin/ld: error in /tmp/llvm_wwflUD/false.o(.eh_frame); no .eh_frame_hdr table will be created. Failed with unknown error (or has stderr output)

Hi, I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish

On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: > Hi, > > I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is

I performed additional benchmarking today and also profiled this. Previously I tried to link clang. I decided to take something much larger today. So what I did was: took chromium sources and built 2 sets of objects. One of them was built with vanilla clang and one with clang+https://reviews.llvm.org/D40352 patch applied. As a result, the second set of object contained multiple .eh_frames (for

On Thu, Mar 20, 2014 at 10:41 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 19 March 2014 17:31, David Blaikie <dblaikie at gmail.com> wrote: >> While comparing debug info between GCC and Clang I found a section >> that only Clang produces and GCC never produces: debug_frame. >> >> It seems (though I haven't verified this with absolute

>>> With GNU gold (GNU Binutils 2.29.51.20171006) 1.14 have an assert: >>> ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o >>> /usr/local/bin/ld: internal error in layout_eh_frame_section, at >>> .././../gold/object.cc:1309 >>> It is that place: >>> https://github.com/gittup/binutils/blob/gittup/gold/object.cc#L1372

>@Grimar: Did you do any profiling of the code? Were the slowdowns >you were seeing fundamental (i.e. due to IO) or could a more optimal >implementation reduce the slowdown? Did you do any end to end >timings for compilation + link time? No, as far I remember I did not profile this. All results I had were about linker timing for linking clang (posted in this thread). I think the