search for: frametable

U-boot for the arndale board splits the memory in 8 contiguous banks and rewrites the memory node. So most of the memory is lost. As the frametable is only able to handle contiguous memory, use the first contiguous banks and warn if some of the memory banks are not used. Signed-off-by: Julien Grall <julien.grall@linaro.org> --- xen/arch/arm/setup.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff -...

...) lib/CodeGen/AsmPrinter.cpp (+19) lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp (+36 -8) lib/CodeGen/README.txt (+5) lib/Target/CBackend/CBackend.cpp (+3 -1) lib/Target/MSIL/MSILWriter.cpp (+3 -1) Second pass at integrating Collector with the compiler. In general, designating the frametable algorithm on a function-by-function basis was beneficial to the implementation. One thing that sticks in my craw is that Collector and TargetMachine still have no way of verifying their mutual compatibility. That's fixable with a followup pass. This is the last patch before the frametab...

Hell all, I am doing some research work on protecting Xen''s data structures. I know there is a direct-map area(about 12M), in which we can get the physical address of the data structure from its virtual address. My question is : are the stack and the heap of Xen both located in this direct-map area? Since I need protect stack and heap data, so it is easy to identify their physical

Hi I'm using a GC that's pretty similar to the OCaml one. It records stack locations using llvm.gcroot, and dumps out a frametable describing the live stack offsets so that the GC runtime can walk them as required. I'm on 2.3, not svn head. I'm having some trouble with pointers being cached in registers across function calls (at least x86 backend, haven't tried others yet). The steps are: 1. Allocate an array (A)...

...o you think of providing a facility like this? That could >> enable several kinds of conservative collectors. A thinko; I meant accurate, not conservative. > I'm not sure I follow what you mean. My initial thought was more akin to getting the labels I needed and representing the frametable at the source level. That's a terrible idea. :) It makes much more sense for the code generator to cooperate with GC. >> The code generator would need to cooperate by: >> >> 1. Inserting nodes for GC points if required, recording the >> corresponding original Ins...

On Aug 14, 2007, at 4:35 AM, Gordon Henriksen wrote: > On Aug 14, 2007, at 06:24, Gordon Henriksen wrote: > >> The two major problems I had really boil down to identifying GC >> points in machine code and statically identifying live roots at >> those GC points, both problems common to many collection >> techniques. Looking at the problem from that perspective

Hi Scott, On Sep 22, 2008, at 20:59, Scott Graham wrote: > I'm using a GC that's pretty similar to the OCaml one. It records > stack locations using llvm.gcroot, and dumps out a frametable > describing the live stack offsets so that the GC runtime can walk > them as required. I'm on 2.3, not svn head. > > I'm having some trouble with pointers being cached in registers > across function calls (at least x86 backend, haven't tried others > yet). Ar...

On Mon, 20 Aug 2007, Gordon Henriksen wrote: >> I'm not sure I follow what you mean. > > My initial thought was more akin to getting the labels I needed and > representing the frametable at the source level. That's a terrible idea. :) > It makes much more sense for the code generator to cooperate with GC. All the GC needs is information about what pointers are live in each stack trace, right? This is all details of implementation of how it extracts that. The GC should...

...tructures breaks binary compatibility (including C >> interop). > > If that is so, and if there is no way around this, then it makes > sense to develop some compatibility mode. How does native C code > generate these tables? I might've conflated two related points. The frametable isn't really at issue with respect to C interop. Rather, the decision to get into the runtime business is. To be specific, C interop doesn't generate frame table entries. It anchors roots by explicitly registering/unregistering root pads with the runtime. Very similar to the paper...

Hi, all Page offline can be used by many purpose, like memory offline, memory power management, proactive action when multiple CE error happen to one page etc. In virtualization environment without guest offline support, we think offline a page usually means replace the old page with a new one transparently to guest. Currently we are trying to add page offline support in Xen environment .

...ary compatibility (including >>> C interop). >> If that is so, and if there is no way around this, then it makes >> sense to develop some compatibility mode. How does native C code >> generate these tables? > > I might've conflated two related points. The frametable isn't > really at issue with respect to C interop. Rather, the decision to > get into the runtime business is. Ok. > To be specific, C interop doesn't generate frame table entries. It > anchors roots by explicitly registering/unregistering root pads > with the runti...

On Mon, 13 Aug 2007, Gordon Henriksen wrote: >> The table is a contract between the specific codegen you're using and the >> GC runtime you're using. This contract is specific to the current ocaml >> code generator. > > Ocaml is compiled statically; this isn't an ephemeral link from JIT to > runtime as might be the case for a Java or Perl program.

...em would be fairly straightforward. > So is there any code to fit the Ocaml GC requirements into LLVM > abilities, ie to use LLVM to generate (eg JIT) code which respect > Ocaml GC requirements. Included in the pending LLVM garbage collection code generation changeset is an Ocaml frametable emitter. See here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-November/ 011473.html In a JIT context--which I am not presently pursing--it would also be possible to generate these tables in memory and spool the records into an active runtime. This is precisely what the ocaml startu...

On 2007-08-13, at 16:33, Chris Lattner wrote: >> The biggest problem is a data structure called the frame table, a >> simple structure for which LLVM seems ill-prepared. For each call >> site in the program, ocaml emits an entry into this table: >> >> key : the return address of the call site >> value : the stack offset of every variable live

Hello All (to Ocaml List & CC LLVM list) As some might probably know, the LLVM compiler http://llvm.org/ has (at least in its latest SVN snapshot) a binding for Ocaml. This means that one could code in Ocaml some stuff (eg a JIT-ing compiler) which uses (and links with) LLVM libraries. http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-November/011481.html

All, I''m posting to the Xen-devel list and the OSDL fastboot list. There are a number of Xen folks who''ll want to look at the code. For the fastboot folks, this is mostly intended as an announcement of the port. Please limit your replies to the list(s) that they applies to, thanks :-) A number of people have expressed interest in kexec support for Xen guests. In

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See