search for: callstack

...x027bdad0" ESI="0xf7627380" EBP="0x027bdb00" EIP="0xf7445ea3" SEGCS="0x00000023" EFLAGS="0x00010202" ESP="0x027bdaa8" SEGSS="0x0000002b"> <callstack> </callstack> <stack> <![CDATA[ 027BDA88 00 00 00 00 00 db 7b 02 - d1 17 28 f7 f8 86 2c f7 ......{...(...,. 027BDA98 00 00 00 00 b8 64 14 00 - f4 4f 62 f7 80 73 62 f7 .....d...Ob..sb. *027BDAA8 47 69...

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 th...

...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, >...

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 : MyJit.dll!MyCurrentFunction() [0x1234567887654321] [0x8765432112345678] MyJit.dll!MyCallingFunction() ... It looks like visual studio get lost while walking up stack....

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.

...te: > >> 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 : >> >> MyJit.dll!MyCurrentFunction() >> [0x1234567887654321] >> [0x8765432112345678] >> MyJit.dll!MyCallingFunction() >...

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

...n Webrick): :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: NoMethodError in <controller not set>#<action not set> WARNING: You have a nil object when you probably didn''t expect it! Odds are you want an instance of Array instead. Look in the callstack to see where you''re working with an object that could be nil. Investigate your methods and make sure the object is what you expect! Show framework trace C:/ruby/lib/ruby/gems/1.8/gems/actionpack-1.9.1/lib/action_controller/routin g.rb:429:in `recognize!'' C:/ruby/lib/ruby/gems/1....

.... If the highest bit of a shadow byte is set, we increment the 7-bit counter (to the maximum of 127; if this is found to be too small we could use separate storage for an additional counter for hot fields). - Memory allocation wrapping: When a heap object is freed, we acquire the callstack and its access pattern in the shadow memory. We may coalesce them based on the allocation/free callstack. The report from the tool to the user at the end of execution would essentially be a list of objects that have some significant fragmented access pattern. We expect the time overhead of...

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 her...

> > 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 DebugInfo tests would be the only wart on the experimental->official code review. I've had a couple long attempts...

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 C!clt_mdct_clear(mdct_lookup * l=0x0111bc04) ?Line 103 + 0x10 bytes C!celt_mode_destroy(CELTMode * mode=0x0111bbd8) ?Line 432 + 0xc bytes C!celt_mode_create(int Fs=96000, int frame_size=258, int * error=0x0017fa88) ?Line 4...