questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[Chris Friesen]

Hi all,

Sorry for the bunch of emails, I'm working on some new stuff and running 
into issues.

For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP 
but not DBCR0_BRT.  Is that just because none of the code paths 
currently using DBCR0_ACTIVE_EVENTS need to check DBCR0_BT?

Also, in sys_debug_setcontext() why does SIG_DBG_BRANCH_TRACING return 
-EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set?  Would it not be possible 
to use DBCR0_BRT?

Thanks,
Chris

-- 

Chris Friesen
Software Designer

500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.friesen@genband.com

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[shiva7]

I have the same question as like above posted by Mr. Chirs. 

Could someone help to understand why the debug BRT bit not handled in debug
context sys call? Intentional or need volunteer to finish up this part :)



--
View this message in context: http://linuxppc.10917.n7.nabble.com/questions-on-CONFIG-PPC-ADV-DEBUG-REGS-DBCR0-BRT-and-DBCR0-ACTIVE-EVENTS-tp70147p81732.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[Scott Wood]

On Tue, 2014-04-22 at 05:43 -0700, shiva7 wrote:
> I have the same question as like above posted by Mr. Chirs. 

I had to google the subject to find what e-mail you were talking about
-- it was posted a year ago:

http://marc.info/?l=linuxppc-embedded&m=136572252330650&w=2

Next time please quote the e-mail if you're trying to revive a thread,
and keep the original poster on CC.

I've quoted it here:

> Sorry for the bunch of emails, I'm working on some new stuff and running 
> into issues.
> 
> For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP 
> but not DBCR0_BRT.  Is that just because none of the code paths 
> currently using DBCR0_ACTIVE_EVENTS need to check DBCR0_BT?

Perhaps it was just an oversight.  I've CCed Dave Kleikamp and Torez
Smith, who added DBCR0_ACTIVE_EVENTS.

> Also, in sys_debug_setcontext() why does SIG_DBG_BRANCH_TRACING return 
> -EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set?  Would it not be possible 
> to use DBCR0_BRT?

Either nobody has gotten around to implementing it, or the semantics
are different in some way (if the semantics are even defined anywhere
-- I couldn't find any documentation).

-Scott

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[Scott Wood]

On Tue, 2014-04-22 at 17:31 -0500, Scott Wood wrote:
> On Tue, 2014-04-22 at 05:43 -0700, shiva7 wrote:
> > I have the same question as like above posted by Mr. Chirs. 
> 
> I had to google the subject to find what e-mail you were talking about
> -- it was posted a year ago:
> 
> http://marc.info/?l=linuxppc-embedded&m=136572252330650&w=2
> 
> Next time please quote the e-mail if you're trying to revive a thread,
> and keep the original poster on CC.
> 
> I've quoted it here:
> 
> > Sorry for the bunch of emails, I'm working on some new stuff and running 
> > into issues.
> > 
> > For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP 
> > but not DBCR0_BRT.  Is that just because none of the code paths 
> > currently using DBCR0_ACTIVE_EVENTS need to check DBCR0_BT?
> 
> Perhaps it was just an oversight.  I've CCed Dave Kleikamp and Torez
> Smith, who added DBCR0_ACTIVE_EVENTS.

...and both of those e-mails bounced, so it may be that nobody who is
listening knows the answer.  Feel free to submit a patch that adds it,
with the changelog explaining why it should be included.

-Scott

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[shiva7]

Thanks Scott.

Apologize for not quoting the old email reference. I assumed the old archive
content always will be in the trail.

Any idea whether the DBCR0 BRT bit actually works(??), if I add  DBCR0 under
sys_debug context call? because this code seems like direct porting and
wondering why on first place not included under debug_context call. 

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.

I can see the debug handler already have HACK to simulate the branch taken
case and SIGTRAP to user space.

Thanks in Advance.



--
View this message in context: http://linuxppc.10917.n7.nabble.com/questions-on-CONFIG-PPC-ADV-DEBUG-REGS-DBCR0-BRT-and-DBCR0-ACTIVE-EVENTS-tp70147p82408.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[Scott Wood]

On Sun, 2014-05-18 at 16:38 -0700, shiva7 wrote:
> Thanks Scott.
> 
> Apologize for not quoting the old email reference.

You did it again. :-)

> I assumed the old archive content always will be in the trail.

It's in the archives (as I noted), but it's a pain to search for it
versus having relevant bits quoted.

> Any idea whether the DBCR0 BRT bit actually works(??),

Do you have reason to believe that it might not?

> if I add  DBCR0 under sys_debug context call? because this code seems
> like direct porting and wondering why on first place not included under
> debug_context call. 

Again, it was probably an oversight, but the people who might know for
sure are no longer reachable.

> 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. :-)

-Scott

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[Deepak Pandian]

unsubcribe linuxppc-dev

On Fri, Apr 12, 2013 at 4:51 AM, Chris Friesen
<chris.friesen@genband.com> wrote:
> Hi all,
>
> Sorry for the bunch of emails, I'm working on some new stuff and running
> into issues.
>
> For CONFIG_BOOKE it appears that DBCR0_ACTIVE_EVENTS includes DBCR0_ICMP but
> not DBCR0_BRT.  Is that just because none of the code paths currently using
> DBCR0_ACTIVE_EVENTS need to check DBCR0_BT?
>
> Also, in sys_debug_setcontext() why does SIG_DBG_BRANCH_TRACING return
> -EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set?  Would it not be possible to
> use DBCR0_BRT?
>
> Thanks,
> Chris
>
> --
>
> Chris Friesen
> Software Designer
>
> 500 Palladium Drive, Suite 2100
> Ottawa, Ontario K2N 1C2, Canada
> www.genband.com
> office:+1.343.883.2717
> chris.friesen@genband.com
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev



-- 
With Regards,
Deepak Pandian
"Deconstructing world one piece at a time"

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[shiva7]

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.



--
View this message in context: http://linuxppc.10917.n7.nabble.com/questions-on-CONFIG-PPC-ADV-DEBUG-REGS-DBCR0-BRT-and-DBCR0-ACTIVE-EVENTS-tp70147p82485.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[shiva7]

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?




--
View this message in context: http://linuxppc.10917.n7.nabble.com/questions-on-CONFIG-PPC-ADV-DEBUG-REGS-DBCR0-BRT-and-DBCR0-ACTIVE-EVENTS-tp70147p82686.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.

Re: questions on CONFIG_PPC_ADV_DEBUG_REGS, DBCR0_BRT, and DBCR0_ACTIVE_EVENTS

[Scott Wood]

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.

-Scott