search for: __foo

Here's what I'm doing: 1. I set __FOO=0 in the current context. 2. I use Dial() and the M(testvar) macro call. 3. The macro-testvar can see ${FOO} just fine. 4. the macro-testvar modifies FOO. I tried: Set(__FOO=1) Set(_FOO=1) Set(FOO=1) 5. When the Dial()ed call hangs up, and the or...

...> >> put_page-> >> free_domheap_pages-> >> shadow_drop_references-> >> shadow_lock -> ..................... second lock Questions: - should shadow lock be recursive? - is shadow lock too coarse grained? It seems to have led to a lot of code refactoring (__foo without lock and foo with lock). But there may be more such instances we haven''t found yet. -Arun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...atalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx10.10.0" %struct._foo = type {} %struct._entry = type { i32, i32, i8* (%struct._foo*, i32, i8*)* } %struct._table = type { i64, i32, i32, [1 x %struct._entry] } %struct.test = type { %struct.__foo, i32 } %struct.__foo = type { %struct._dispatch } %struct._dispatch = type { %struct._entry*, i8* (%struct._foo*, i32, i8*)* } @str = private unnamed_addr constant [8 x i8] c"table_f\00" @str.2 = private unnamed_addr constant [11 x i8] c"dispatch_f\00" ; Function Attrs: nounwi...

Hi Folks, I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say

...4-S128" > target triple = "x86_64-apple-macosx10.10.0" > > %struct._foo = type {} > %struct._entry = type { i32, i32, i8* (%struct._foo*, i32, i8*)* } > %struct._table = type { i64, i32, i32, [1 x %struct._entry] } > %struct.test = type { %struct.__foo, i32 } > %struct.__foo = type { %struct._dispatch } > %struct._dispatch = type { %struct._entry*, i8* (%struct._foo*, i32, > i8*)* } > > @str = private unnamed_addr constant [8 x i8] c"table_f\00" > @str.2 = private unnamed_addr constant [11 x i8] c&q...

> On May 23, 2019, at 2:05 AM, James Henderson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I discussed this with Seiya off the mailing list yesterday, and this was the suggestion we came up with, on the basis that GNU objcopy has support for the renaming for GDB support, but it might be confusing to people who are new to the system, so we provide a more expected output

...what this is. You were running this on Linux, right? On MacOS I think the symbol is getting double mangled while going through MCJIT::getSymbolAddress, hence the failure: The IR level foo function gets compiled to "_foo" in the object file, and then "_foo" gets mangled to "__foo" when we look it up. Linux doesn't do assembly level name-mangling, so this bug doesn't show up there. Since applying this fixes Linux, and leaves MacOS no more broken than before, I'll put it in. Hopefully I can figure out a fix for MacOS soon. Thanks again Charlie. - Lang. O...

...ough regmaks) Here are my questions related to this example: 1) Is there any pass or code in LLVM which is responsible for caller saved register for Physical Registers? By looking at InlineSpiller.cpp it is responsible for VReg spilling. 2) If such pass exists then why R15 is not saved around call __foo? 3) Why _bar is saving %rax in above code? Please help! Sincerely, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160630/64436cd3/attachment.html>

So apparently 1.8.4 is soon forthcoming. We need testing against it. Could someone help out with that? I believe Ara already checked into some of the issues, do you know if those are resolved, Ara? -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager

...acters will cause them to be inherited indefinitelty. > (Only works in CVS HEAD, not yet implemented in Asterisk 1.0.9.) > > Note that for retrieval purposes these variable names do not > need to include the underscores. > > [TestInherit] > exten => 100,1,SetVar(__FOO=5) > exten => 100,2,Dial(Local/test@CheckInherit) > exten => test,1,NoOp(${FOO}) > > will result in FOO being inherited. Without the underscores, > the new local channel would start with a clean slate." > > > __________________________________________...

...ther inherited. Prepending two _ characters will cause them to be inherited indefinitelty. (Only works in CVS HEAD, not yet implemented in Asterisk 1.0.9.) Note that for retrieval purposes these variable names do not need to include the underscores. [TestInherit] exten => 100,1,SetVar(__FOO=5) exten => 100,2,Dial(Local/test@CheckInherit) exten => test,1,NoOp(${FOO}) will result in FOO being inherited. Without the underscores, the new local channel would start with a clean slate."

Hi, I'm trying to emit FP_ROUND f64 -> f32 considering a mips target that only supports single float point operations. The problem is that f32 is considered legal on this target but f64 doesn't and the only way I can codegen this instruction is using setConvertAction(MVT::f64, MVT::f32, Expand), which issues a EmitStackConvert. What if I want a libcall instead? What should I do? The

...are my questions related to this example: > 1) Is there any pass or code in LLVM which is responsible for caller saved > register for Physical Registers? By looking at InlineSpiller.cpp it is > responsible for VReg spilling. > 2) If such pass exists then why R15 is not saved around call __foo? > 3) Why _bar is saving %rax in above code? > > Please help! > > Sincerely, > Vivek > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160630/6e157a83/attachment-0001.html>

Thank you for the explanation. Does that mean r_symbolnum is basically redundant in that case? Also, let me ask you how to handle the following use case which is somewhat related. Currently in MCJIT for MachO we are relocating all the debug sections. Eventually (as ELF does), it would be good to avoid this. However, this means that the debugger would have to handle relocations (as lldb currently

..., right? >> >> On MacOS I think the symbol is getting double mangled while going through >> MCJIT::getSymbolAddress, hence the failure: The IR level foo function gets >> compiled to "_foo" in the object file, and then "_foo" gets mangled to >> "__foo" when we look it up. Linux doesn't do assembly level name-mangling, >> so this bug doesn't show up there. >> >> Since applying this fixes Linux, and leaves MacOS no more broken than >> before, I'll put it in. Hopefully I can figure out a fix for MacOS soon....

...d3644",u1559):d1543, u1546<R13>(d785):] s1547: MOV32r0 [d1548<ESI>(+d3206,\~d3643",u1560):d1545, d1549<EFLAGS>!(d1540,\~d3642",):] s1550: MOV64rm [d1551<R11>(+d3206,\~d1554",u1562):d1548, u1552<RIP>(+d3206):u1537] s1553: CALL64pcrel32 __foo [\~d1554"<#1073741833>!(d1551,d1579,):, \~d3642"<#1073741833>!(d1549,,):, \~d3643"<#1073741833>!(d1548,,):, \~d3644"<#1073741833>!(d1545,,):, \~d3645"<#1073741833>!(d1543,,):, \~d3646"<#1073741833>!(d1535,,):, \~d3647"<#10737...

Hi all, Starting from Chapter 4 of the Kaleidoscope tutorial (where the JIT support is added), there's some strange behaviour, ready> def foo(x y) x+y; ready> Read function definition: define double @foo(double %x, double %y) { entry: %addtmp = fadd double %x, %y ret double %addtmp } ready> foo(1, 2); ready> Evaluated to 3.000000 ready> foo(3, 4); ready> Evaluated to

Hi Andi, Here's a little batch of cleanups: - re-enable VDSO when PARAVIRT is enabled - make the parainstructions symbols match the other altinstructions naming convention - add kernel command-line options to disable altinstructions for smp and pv_ops Oh, and I'm mailing your noreplacement patch back at you, for no particularly good reason. J --

Hi Andi, Here's a little batch of cleanups: - re-enable VDSO when PARAVIRT is enabled - make the parainstructions symbols match the other altinstructions naming convention - add kernel command-line options to disable altinstructions for smp and pv_ops Oh, and I'm mailing your noreplacement patch back at you, for no particularly good reason. J --

Hi Scott, That #1073741833 is a register mask. They are treated as aggregate registers (essentially sets of registers), so if it includes R9D and R11D, it will be treated as being aliased with both. These separate defs are there because they reach disjoint registers. -- Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development From: Scott