This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Saving all register of Boehm's Stop-World of hypermodern i686, is it reliable?


| J.C. writes:
| > | J.C. writes:
| > | > In boehm-gc/pthread_stop_world.c from GCJ-4.3,
| > | > i don't see any specific information of a modern CPU like AMD Athlon64 | > | > AM2 or Intel Pentium-M CoreDuo.
| > | > | > | > ( to see GC_with_callee_saves_pushed() )
| > | > | > | > In my opinion, the registers & flags that must to be saved are:
| > | > | > | > * GP registers & flags (like eax,ebx,..,ebp,esp)
| > | > * FP registers & flags (like ST(0),..,ST(7))
| > | > * MMX registers & flags (from MMX)
| > | > * XMM registers & flags (from SSE, SSE2, SSE3, SSE4, ..)
| > | > * 3DNow+ registers & flags (very specific from AMD)
| > | > * future registers & flags of extensions of new microprocessors.
| > | > | > | > If not all register of a hypermodern i686 is saved then it can | > | > soft-crash the application with a certain probability, and it won't be | > | > good for future searching of unknown bugs.
| > |
| > | I think you need to explain to us where you see a vulnerability. In
| > | particular, do you expect pointers to be saved in XMM registers? If
| > | so, please explain why you expect this.
| > | > To imagine a theatre of 2 actors,
| > the main actor "M" and the Stop-World actor "SW":
| > | > M : i'm calling to e.g. app_quick_memcpy that it uses instructions of cache's
| > prefetching and XMM registers to accelerate the copy, thanks to the e.g.
| > AMD Athlon Optimization manual. Inside of app_quick_memcpy, it does callings
| > to several functions.
|
| Well, that wouldn't be enough to cause any pointers to be lost,
| because they'd still be set in the source location. To actually lose
| live pointers you'd have to copy to XMM registers and erase the source
| memory block before writing the data to the destination block, thus
| hiding the data from the gc.


Just, in this instant, when there are data (e.g. pointers) in XMM registers,
it can't be interrupted, nothing can call to Stop-World, .. but it's possible
to be violated.

There is an easy paradox's rule,

"if a GP register (32 bit) can contain a pointer
then a XMM register (128 bit) can contain upto 4 pointers"

but "i save to the stack the GP register and not the XMM register" why?

Proved, the XMM register must to be saved to the stack as any GP register.

| There are other possible ways to hide data from the gc, such as
| rotating an address or XORing it by a constant.

Of course.

| > SW: now, i stop your world and start to collect information of your world,
| > and i suppose that this traced information will be full.
| > | > M: i've unexpected result of app_quick_memcpy, why? why? i don't find the
| > app_quick_memcpy's BUG. It's harmful for my brain.
|
| No doubt.
|
| Andrew.


J.C.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]