Hi Kun, Den 8. apr. 2010 23.43 skrev <[email protected]>:
> Hi Erik, > > In my understanding, CopyFrom uses this code's relocation info to find the > corresponding instruction to update. So the two function calls to > You are right, I misread the code. > set_target_address and set_target_object should patch the code within > instruction_start() and instruction_start() + instruction_size(). Please > correct me if I get something wrong. > I have been very slow to answer this for which I apologise. My slowness was related to my worries that we might miss some cache flushes that should be there. Therefore I have changed the ARM simulator to check the icache operations for correctness. The change is not completely done, but you can download the patch set from http://codereview.chromium.org/1523030/show and try it out. If your new code runs the tests with the new stringent icache checking that would allay my fears and allow us to move forward on this. -- Erik > > Thanks, > -Kun > > In the current changes, I think we don't need CPU::FlushICache > >> in > >> set_target_address_at. > >> 1. set_target_address_at is called by set_target_object and > >> set_target_address. > >> 2. set_target_object is called in objects.cc followed with > >> "CPU::FlushICache(instruction_start(), instruction_size())". > >> 3. calls to set_target_address > >> 3.1 the function call to set_target_address in objects.cc is also > >> followed > >> by a > >> FlushICache. > >> > > > > The region of memory flushed by that call to FlushICache is not the same > > as > > the region of memory written by the call to set_target_address. > > > > > >> 3.2 the function call to set_target_address in ic-inh.h is to update the > >> target > >> of a function call. In macro-assembler-arm.cc, we remain the use of "ldr > >> + > >> blx"; > >> no movw/movt is generated for this case. Thus, set_target_address will > >> update > >> the const pool, not the ICache. > >> > > > > It is important that we assert that this is really the case. One way to > > do > > that might be to split set_target_address into two versions, one called > > set_target_address and the other called set_target_address_noflush. In > > one > > of them we do the flush and in the other we assert that we are patching > > the > > constant pool and not the instruction. Things still have to compile on > > other platforms, including valgrind-on-ia32 where the cache flush > > instructions are used to notify valgrind that code has changed. > > > > > >> 3.3 set_target_address is called in debug.cc, mark-compact.cc, and > >> liveedit.cc. > >> Currently, we're not quite clear about what those function calls do and > >> how > >> to > >> triger those function calls. If you have any insights on this, please > >> let > >> us > >> know. > >> > > > > They should be triggered by running the debug tests. They are used for > > debugging. You have to compile with -DENABLE_DEBUGGER_SUPPORT for this > > code > > to be excercised. > > > > > > > >> > >> -Kun > > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
