questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS
scottwood at freescale.com
Fri May 30 07:08:28 EST 2014
On Mon, 2014-05-26 at 15:20 -0700, shiva7 wrote:
> shiva7 wrote
> > Thanks again Scott.
> >> Any idea whether the DBCR0 BRT bit actually works(??),
> >> Do you have reason to believe that it might not?
> > I'm facing a strange problem which was not there on server processor. Let
> > me try to give brief flow.
> > Server :
> > Set BE bit (thru system call or sigreturn) for specific thread -> for
> > every branch -> trace exception -> Normal exception prolog
> > (STD_EXCEPTION_COMMON) SRR0 and SRR1
> > Embedded/BOOKE:
> > Set DE & BRT bit (thru system call or sigreturn) for specific thread ->
> > for every branch taken -> Debug exception -> DEBUG_DEBUG prolog ->
> > return_dbg_except DSRR0 & DSRR1
> > In server case, able to capture the branches as expected, but wherein
> > BOOKE though branch taken exception are generated, at the certain stage
> > (mostly after turn on BRT & DE bit) user process is deviated (not taking
> > the same flow as like server) and leading to different
> > corruption/unexpected behavior.
> >> And also, anything special required for "server" family application code
> >> porting here ?? as because in server family the trace exception used to
> >> viz
> >> NORMAL exception proglog and uses SRR0 and SRR1 but in this ISA/embedded
> >> case have dedicated DEBUG_DEBUG prolog and dedicated registers DSRR0 and
> >> DSRR1.
> >> IIRC the branch taken mechanism does have different semantics than the
> >> equivalent mechanism on server. You can find discussion of this in the
> >> archives. :-)
> > Most of the discussions so far I have surfed are related to branch
> > taken/fall through(not taken) semantics related. But, in general, if I
> > have an application running on server where tracing was based on BE bit
> > and same can run on e500mc with DE & BRT combination?
> > Thanks In Advance.
> Could someone help on this regard?
I think you'll need to debug it, and send a patch if you find a bug. As
for "in general" that depends on whether your application cares about
the difference in semantics that was noted.
More information about the Linuxppc-dev