search for: callstacks

I'm not sure if this is a wine or nvidia related bug, so I'd really appreciate some help... After upgrading to nvidia 295.20 this game fails to start, giving the following error: Code: <?xml version="1.0" encoding="ISO-8859-1"?> <crash_report> <version_cookie /> <platform>win32</platform> <os_info>Version 5.1 Build 2600

Hi, for programs linked with lld it's substantially slower to get callstacks in gdb, in comparison to gold-linked programs. Two measurements: lld gold 15 sec 3 sec 6 sec 2 sec This is a debug build, rather large binaries (lots of templates). I have seen even worse performance for debug+UBSan builds. I think code size (and therefore DWARF size) has an impact. Is the...

...being built by gcc or clang? Cheers, Rafael Rafael Avila de Espindola <rafael.espindola at gmail.com> writes: > Martin Richtarsky via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Hi, >> >> for programs linked with lld it's substantially slower to get callstacks >> in gdb, in comparison to gold-linked programs. Two measurements: >> >> lld gold >> 15 sec 3 sec >> 6 sec 2 sec > > Are both using --gdb-index? Can you try lld trunk if so? > > Is any of the programs you tested open source? > > Cheers, > R...

Hi, I'm using IR and MCJIT to compile a script language. I debug it with on the fly generated .pdb files. During debugging, almost each time I step into a function, I loose information about calling function inside the visual studio callstack view or I have a bunch of pure addresses in the callstack in between the current function and the calling function, for example :

Hello! I'm trying to get stack-passed arguments working on my back-end, and I've run into an issue I can't resolve. I got the code working to the point that function F1 can call F2 with 5+ arguments fine (we pass 4 in registers). The problem is if F2 then calls another function F3 with 5+ args, then all reading of the stack/call frame is off, the address doesn't get compensated

Martin Richtarsky <s at martinien.de> writes: > Rafael Avila de Espindola wrote : >>> Maybe gdb needs to fall back to slower line number resolution because >>> e.g. >>> low and high bounds cannot be retrieved and debug_line_address is 0? >> >> It is hard to know without a reproducible. I tried gdb on clang itself >> build with both clang and

Martin Richtarsky <s at martinien.de> writes: > Hi, > >> Is the program being built by gcc or clang? > gcc 6, but I can try clang. > >> Are both using --gdb-index? Can you try lld trunk if so? > No. > >> Is any of the programs you tested open source? > No. > > Here is some more info. I enabled "set verbose on" in gdb. With this >

Martin Richtarsky <s at martinien.de> writes: > Output looks as follows [1] Seems sh_offset is missing? That is what readelf prints as Off > [17] .rela.text RELA 0000000000000000 071423 001728 18 > 1 4 8 The offset of rela text should have been aligned, but it is not. Can you report a bug on icc? As a work around using the gnu assembler if possible

Martin Richtarsky <s at martinien.de> writes: > Rafael Avila de Espindola wrote: >>> I will retry with clang trunk, when it reproduces I will build some >>> other >>> large project (that has DSOs) using our compile/link options (they are >>> not >>> that special, I think). >> >> If you can try lld trunk too that would be awesome.

I've always just hacked support for this in to the various JITs (for JuliaLang, in our debuginfo.cpp file), by setting the no-frame-pointer-optim flag in the IR, then creating and populating a dummy unwind description object in the .text section, and registering that dynamically. Some day I hope to actually just register the .pdata/.xdata sections with the unwinder. PDBs are a bit different

Rui Ueyama <ruiu at google.com> writes: > On Tue, Dec 5, 2017 at 1:22 PM, Rafael Avila de Espindola < > rafael.espindola at gmail.com> wrote: > >> Martin Richtarsky <s at martinien.de> writes: >> >> > Output looks as follows [1] Seems sh_offset is missing? >> >> That is what readelf prints as Off >> >> > [17] .rela.text

On 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >

Greetings everyone. I''m learning RSpec and am pretty fresh to Ruby/Rails, but am so excited I can''t help jumping in. I''m running before I can walk here. :-) Yesterday I tried outputting test results to HTML instead of colorized plain text. It looked like there were some entries in the change log for the 1.0.5 release allowing RSpec to do what I wanted. I tried

I used generate/scaffold to create simple CRUD screen that works perfectly with Webrick. I wanted to attempt to run the same ROR app on Apache. I followed the instructions found at http://wiki.rubyonrails.org/rails/pages/Fast+CGI+and+Apache2+for+Windows+XP with the alternate ending found at http://wiki.rubyonrails.org/rails/pages/Fast+CGI+and+Apache2+for+Windows+wit hout+VirtualHosts. I have

Please reference the prior RFC on EfficiencySanitizer. This is one of the performance analysis tools we would like to build under the EfficiencySanitizer umbrella. ==================== Motivation ==================== An application is running sub-optimally if only part of the data brought into the cache is used, which we call cache fragmentation. Knowing the cache fragmentation information

Hi Björn, I'm not sure I understand what you are actually trying to achieve. Do you want to be able to debug from your main code, and step into the JITed code? Do you want to be able to set breakpoints, list callstacks, etc in the JITed code? Do you want to, from a crash, identify where in your JITed code it went wrong? The first two are definitely one or more order(s) of magnitude harder to solve than the third one, since you basically have to tell your debugger that "I've now added some more code here...

> > Should we just make it a normal target? > My only remaining reservation here - the generic DebugInfo tests, which presumably due to an unimplemented 16-bit branch somewhere deep in the llvm-objdump callstack. The AVR backend passes virtually all of the LLVM test suite but these when avr-unknown-unknown is set as the default target. It feels like the inclusion of ~80 XFAILs for these

On Fri, Sep 12, 2008 at 11:40 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > AFAIK, 128-bit integers should work just fine on x86 with LLVM. Bad example then, I meant I am wondering about how I should have my language handle things that are platform specific, whether I should expose them and let the user make 'best judgment calls' which could break on the distributed

This language has functions that will have to be tail-called due to having the ability to 'pause' its callstack, but some functions will not and I was just planning to call them like normal functions. I am wondering, would it be 'faster' (at execution of the compiled code) to just put everything in the tail-call way, or is it still faster to call functions like normal when I can?

Hi I noticed a crash issue when I passed the following values: celt_mode_create(96000, 258, &e); CELTMode->mdct.kfft[0] is not initialized after calling?clt_mdct_init() and when?celt_mode_destroy() is called it tries to dereference this value in kiss_fft_free(). -- Bjoern Here's the callstack: !kiss_fft_free(const kiss_fft_state * cfg=0x00000000) ?Line 650 + 0x3 bytes