search for: macpherson

Hi Rafael, comment explanation added now. Thanks. On Tue, Jan 14, 2014 at 8:31 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > LGTM with a comment explaining the issue. > > On 20 December 2013 03:50, Andrew MacPherson <andrew.macp at gmail.com> > wrote: > > Thanks Joerg. > > > > I've made the change you suggested and verified that it still works. I > think > > the noinline is still required though as this function can be called > from a > > couple of places and gd...

...ouple of places and gdb will want to set its breakpoint on the single function address. Let me know if you think otherwise though. Cheers, Andrew On Fri, Dec 20, 2013 at 11:52 AM, Joerg Sonnenberger < joerg at britannica.bec.de> wrote: > On Fri, Dec 20, 2013 at 11:18:46AM +0100, Andrew MacPherson wrote: > > This patch forces it to leave the call using the method described here in > > the 'noinline' section: > > Use asm volatile("":::"memory") to make sure that it doesn't leave > trackes. The noinline can likely go in that case... > &gt...

...ny suggestions to look into, or more debug info required? The box is running centos 4.3 final, up to date with the latest versions of CentOS updates,, it's running something like 3.0.10 or .11 - can't recall. 1:22 am. Off to bed... Thanks. -----Original Message----- From: samba-bounces+dmacpherson=mainframe.ca@lists.samba.org [mailto:samba-bounces+dmacpherson=mainframe.ca@lists.samba.org] On Behalf Of Derrick MacPherson Sent: Thursday, August 10, 2006 5:47 PM To: samba@lists.samba.org Subject: [Samba] XP clients disconnected during trasnfer of larger files tothe samba server i'm having...

...the linux kernel? Maybe you have already encountered this and possibly accomplished it as well. I want to use your ISA instead of say an i386 or AMD64. I only recently became aware of your project, so none of this may be new to you. Please be kind in your responses. Thank you, Xavian-Anderson Macpherson Shingoshi -- -------------- next part -------------- A non-text attachment was scrubbed... Name: Shingoshi.vcf Type: text/x-vcard Size: 219 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070308/507ecfe8/attachment.vcf>

Wouldn't LLVM_ATTRIBUTE_USED be the correct thing here to prevent dead stripping, if that's the problem? On Wed, Jan 15, 2014 at 8:46 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > LGTM. Do you have commit access? > > On 15 January 2014 00:27, Andrew MacPherson <andrew.macp at gmail.com> wrote: > > Hi Rafael, comment explanation added now. Thanks. > > > > > > On Tue, Jan 14, 2014 at 8:31 PM, Rafael Espíndola > > <rafael.espindola at gmail.com> wrote: > >> > >> LGTM with a comment explaining the i...

...> that’s visible via either the ELF headers or the DWARF information. Do you > have functions that don’t show up in either of those places? > > > > -Andy > > > > *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On > Behalf Of *Andrew MacPherson > *Sent:* Wednesday, November 13, 2013 9:23 AM > *To:* Reid Kleckner > *Cc:* llvmdev at cs.uiuc.edu > *Subject:* Re: [LLVMdev] Stack traces from JIT code > > > > We implemented a similar solution for handling crashes in production but > one issue we came across with MCJIT...

Yeah, take a look at the IntelJITEventListener code (in lib/ExecutionEngine/IntelJITEvents). It uses the debug info to find function names. -Andy From: Andrew MacPherson [mailto:andrew.macp at gmail.com] Sent: Wednesday, November 13, 2013 1:12 PM To: Kaylor, Andrew Cc: Reid Kleckner; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack traces from JIT code Hi Andy, In the NotifyObjectEmitted method of our derived JITEventListener class we use the begin_symbol() it...

Hi, We switched from compiling LLVM with gcc to clang (3.3) and it appears that clang (correctly I think) optimizes away the GDBRegistrar's __jit_debug_register_code() function that's used to trigger reading debug info from JIT-ted code, breaking GDB support. This patch forces it to leave the call using the method described here in the 'noinline' section:

On Fri, Dec 20, 2013 at 11:18:46AM +0100, Andrew MacPherson wrote: > This patch forces it to leave the call using the method described here in > the 'noinline' section: Use asm volatile("":::"memory") to make sure that it doesn't leave trackes. The noinline can likely go in that case... Joerg

If it's a Windows-only thing the correct tests would be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows regardless of output type, I had meant to file a bug about this but > had apparently forgotten to do so. I think the check needs to be that the > target is Windows and ignor...

...m.sin.f32 intrinsic, as the X86 processor family does have an instruction for that, but I still get the same problem. While you may still be right, there is at least something else going on as well. Thanks for your input, though. Taco. ---------------------------------------- From: "Andrew MacPherson" <andrew.macp at gmail.com> Sent: Thursday, September 19, 2013 10:36 AM To: taco at heddesit.nl Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] JIT compiled intrinsics calls is call to null pointer Hi Taco, We had a similar issue where a math intrinsic was being converted to a call...

We implemented a similar solution for handling crashes in production but one issue we came across with MCJIT was that the NotifyFunctionEmitted call from the old JIT was replaced with NotifyObjectEmitted. The ObjectImage used by NotifyObjectEmitted does have a way of iterating symbols but non-external functions used in the module didn't seem to appear in this list so we were left with some

...Emitted you should be able to get to any function that's visible via either the ELF headers or the DWARF information. Do you have functions that don't show up in either of those places? -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Andrew MacPherson Sent: Wednesday, November 13, 2013 9:23 AM To: Reid Kleckner Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Stack traces from JIT code We implemented a similar solution for handling crashes in production but one issue we came across with MCJIT was that the NotifyFunctionEmitted call from the ol...

...rrect tests would be: > > if (NumBytes >= 4096 && STI.isOSWindows()) { > > and > > if (Subtarget->isTargetWindows()) > > where > > bool isOSWindows() const { return TargetTriple.isOSWindows(); } > > Yaron > > > > 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > >> Glad that helped! As I understand it __chkstk is always required on >> Windows regardless of output type, I had meant to file a bug about this but >> had apparently forgotten to do so. I think the check needs to be that the >> target...

I have tried this many times in the past. But I've never been fully successful on running httpd on Linux using Wine. I would just like to know if it's possible, and how to go about it. It seems like it should be a straightforward process. Xavian-Anderson Macpherson Shingoshi

.... > > So, should I patch both tests? > Is the correct patch removing the test isTargetCOFF() completely? > Or enabling it for both COFF or ELF tarrgets? > I mean - is there any X86 target that does NOT require this stack checking? > > Yaron > > > > 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > >> Hi Yaron, >> >> If you're outputting ELF on Windows this sounds like an issue we ran into >> where __chkstk calls weren't being output in the assembly due to an >> explicit check for COFF output. Once stack allocations i...

First let me admit that I'm completely uninformed here! 1. Will llvm produce errors if llc is used to compile itself? 2. Will make produce subsequent errors if compiled first by llc/llvm? 3. Can llc be used to compile the entire Linux toolchain? Shingoshi --

...lem thus it is probably required for other reasons. So, should I patch both tests? Is the correct patch removing the test isTargetCOFF() completely? Or enabling it for both COFF or ELF tarrgets? I mean - is there any X86 target that does NOT require this stack checking? Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Hi Yaron, > > If you're outputting ELF on Windows this sounds like an issue we ran into > where __chkstk calls weren't being output in the assembly due to an > explicit check for COFF output. Once stack allocations in a given function >...

Hi, I'm wondering about the status of Windows x64 unwind info in LLVM. We're trying to print a simple stack trace on Windows exceptions, including function names of JITted code (which we can roughly derive using addresses from a JITEventListener). While this works fine in 32-bit mode, we're unable to properly walk the stack in 64-bit since the unwind info doesn't seem to be

...words = yes passdb backend = tdbsam logon home = wins support = true server string = %h server (Domain Controller) unix password sync = yes logon path = add user script = /usr/sbin/useradd -m %u domain logons = yes -- Derrick MacPherson <dmacpherson@mainframe.ca>