Hi Alexandre, fixing any issues that you find and adding additional support that 'stop' does not provide sounds good to me. Adding a section to the wiki sounds like a great idea as well.
Thanks, -- Mads On Wed, Sep 29, 2010 at 9:15 AM, Alexandre Rames <[email protected]> wrote: > Hi, > Thanks for your comments. > Sorry for this useless patch. considering the stop instruction it does not > add much; I was not aware of this feature and needed something similar. > The manual breakpoints did not have a string description feature, but added > an enable / disable feature and some simple counter information. > I also found a few interesting issues while reading the "stop" feature code: > - The way stops are generated does not look very safe: > void Assembler::stop(const char* msg) { > emit(15 << 28 | ((intptr_t) msg)); > [...] > } > The Simulator decodes the stop and gets the string address with: > const char* str = (const char*)(instr->InstructionBits() & 0x0fffffff); > Shouldn't there at least be a check when we generate the stop? > > - Also the stop encoding could match a BLX with an immediate value!!! > Luckily it is defined but never used. I did not look in details at how the > Simulator would handle this. > void Assembler::blx(int branch_offset) { // v5 and above > [...] > emit(15 << 28 | B27 | B25 | h | (imm24 & Imm24Mask)); > } > > - There also seems to be something wrong > with Simulator::DecodeUnconditional() . It looks like no load halfword > instruction in the ARM ISA actually use the special_condition code... > If you are interested, I could have a look at all this, fix what needs to > be, and at the same time merge the functionalities and implementation of > stop and "manual breakpoints". I could also add some documentation to the > wiki about debugging with the ARM Simulator. It would maybe save other > people from later trying to write another similar debug feature. > Regards, > Alexandre > > On Tue, Sep 28, 2010 at 6:18 PM, <[email protected]> wrote: >> >> Thanks for the patch. >> >> What does this add to what is already there with the stop instruction? I >> have >> been doing lots of debugging of the generated arm code on the simulator >> using >> the stop instruction. Here is a session after adding a stop("inlined >> load") call >> just before an inlined load: >> >> Simulator hit inlined load >> 0xf53880f4 e3110001 tst r1, #1 >> sim> disasm >> 0xf53880f4 e3110001 tst r1, #1 >> 0xf53880f8 0a000089 beq +556 -> 0xf5388324 >> 0xf53880fc e5117001 ldr r7, [r1, #-1] >> 0xf5388100 e59f92a8 ldr r9, [pc, #+680] >> 0xf5388104 e1570009 cmp r7, r9 >> 0xf5388108 1a000085 bne +540 -> 0xf5388324 >> 0xf538810c e5911000 ldr r1, [r1, #+0] >> 0xf5388110 e1807001 orr r7, r0, r1 >> 0xf5388114 e3170001 tst r7, #1 >> 0xf5388118 0a000003 beq +20 -> 0xf538812c >> sim> p r1 >> r1: 0xf600e229 -167714263 >> sim> po r1 >> r1: >> 0xf600e229: [JSObject] >> - map = 0xf535cb81 >> - prototype = 0xf600dbd1 >> { >> #length: 0xf539ed51 <Proxy> (callback) >> 0: 0xf539fdf1 <String[5]: isNaN> >> 1: 0xf53c0a01 <JS Function GlobalIsNaN> >> 2: 0xf539fe05 <String[8]: isFinite> >> 3: 0xf53c0a21 <JS Function GlobalIsFinite> >> 4: 0xf539fe19 <String[8]: parseInt> >> 5: 0xf53c0a41 <JS Function GlobalParseInt> >> 6: 0xf539fe2d <String[10]: parseFloat> >> 7: 0xf53c0a61 <JS Function GlobalParseFloat> >> 8: 0xf539c2cd <String[4]: eval> >> 9: 0xf53c0a81 <JS Function GlobalEval> >> 10: 0xf539fe45 <String[10]: execScript> >> 11: 0xf53c0aa1 <JS Function GlobalExecScript> >> } >> >> sim> stepi >> 0xf53880f8 0a000089 beq +556 -> 0xf5388324 >> sim> stepi >> 0xf53880fc e5117001 ldr r7, [r1, #-1] >> sim> c >> Simulator hit inlined load >> 0xf53880f4 e3110001 tst r1, #1 >> sim> >> >> >> >> http://codereview.chromium.org/3440028/show >> >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
