[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

executing malloced memory on ia64 or sth else? (SableVM porting)



Hi!

I am trying to get the fastest, inlined-threading SableVM engine
working on IA64. SableVM already works in inlined threading mode
on i386, PPC and Alpha, which is 64bit just like ia64.

The way inlined-threading engine works is a bit similar to a compiler.
The difference is that it uses assembler pieces which are originally
compiled by compiler. SableVM puts these pieces in groups where possible
and executes them together. That gives the speed. I don't want to go
into details too much.

Simplyfing the whole thing - it copies some code to malloced memory
and then jumps to it, by executing:
goto *(pc->implementation);
where implemenation points to the code that is to be executed.

  (gdb) print (char*)pc->implementation
  $29 = 0x6000000000022800 "\v\220àK?# \001H  "

After the goto I keep getting this error every time when the goto
is executed:
  (gdb) c
  Continuing.
  Program received signal SIGSEGV, Segmentation fault.
  0x6000000000022800 in ?? ()

The strange thing is, that it segfaults immediately, at the same
address where the code starts. I think there are possibilities:

1. the memory at the address has not been allocated
2. the first assembler instruction is not recognized by CPU
3. the memory page we have written the data to - is not executable
4. the caches are not flushed (not coherent) and we dont acutally
     execute the code that has been just written

I'd like to eliminate them one by one, so - the first 2 are rather
impossible because sablevm works on alpha which is very similar to
ia64, and I traced execution of the functions building the code to
be executed and I think it works OK.

I am not not sure how to make gdb show me the code in hexadecimal or
sth. but even if I knew - I haven't seen tables of binary representation
of assember accepted by ia64. Would you be able to help here?

But I hope you can help me a bit with 3 and 4.

Ad. 3 - the memory used as destination for code to be executed is
simply malloced. But maybe there's some extra operation that need
to be done on ia64 to execute code in that memory?

ad. 4 - we need to flush the cache to assure coherency between data
cache, main memory and instruction cache. The function used for that
is this:
static inline void _svmf_iflush (_svmt_word *pword) {
 __asm__ __volatile__ ("fc %0;;; sync.i;;; mf;;; srlz.i;;;"::
                        "r" (pword):"memory");
}

I tried many combinations (very simillar), but finally I copied the
above line from
http://www.atomised.org/docs/XFree86-4.2.1/compiler_8h-source.html
(BTW: - it seems that fc.i is not supported by GCC? FWICS in the
docs from Intel - fc.i would be more economic here as it does
_exactly_ what we need and nothing more - maybe it would be possible
to put hex code of fc.i here by hand?)

I'll be very thankful for any ideas and suggestions

					Grzegorz B. Prokopski
-- 
Grzegorz B. Prokopski <gadek@debian.org>
Debian http://www.debian.org/

Attachment: signature.asc
Description: PGP signature


Reply to: