On 09/28/2014 15:34, Maciej W. Rozycki wrote: > Joshua, > > I can't help you with the problem, but I can confirm one of your guesses: > >> I am guessing at a few things here: >> >> - Because ll/sc are atomic, gdb doesn't let you step through them, which is >> why the instruction pointer jumps over the 'li' and 'sc' insns. > > -- this is exactly the case, GDB tries to be smart enough and when it sees > an LL or LLD instruction it examines code that follows to find a matching > SC or SCD instruction and any other exit points from the atomic section > and sets internal breakpoints correctly to let the code fragment run at > the full speed even if single stepping. Otherwise the exception taken at > each single step would cause the conditional store instruction to always > fail -- which might not be a big issue if you were knowingly stepping code > e.g. with `stepi', but would cause big harm in implicit stepping through > unknown or unrelated code such as when a software watchpoint is active. > > See `deal_with_atomic_sequence' in gdb/mips-tdep.c if curious about the > details. Ah ha, that does explain it! Though I don't think it's an issue with ll/sc in the R10000. It's something with gcc's builtin __atomic_* functions I think, though I still haven't ruled the kernel out yet, either. I have no way to step through the kernel syscall to make that determination, though, so I'm focusing more on gcc as time permits. Hopefully, the gcc maintainers will find time to look into PR61538 some more soon. Thanks! -- Joshua Kinard Gentoo/MIPS kumba@xxxxxxxxxx 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
