[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tcf-dev] Problem planting breakpoints
|
On 05/19/2014 05:27 PM, Stefan.Falk@xxxxxxxxxxxx wrote:
1. PROGRAMMING_SUCCEEDED gets raised
There you should see calls to cpu_bp_plant after the contexts get
created right?
Well, I have changed it a little bit now and so I create the contexts even before PROGRAMMING_SUCCEEDED gets raised (this is save since it does not affect the way I obtain debug information) - but no - I don't see cpu_bp_plant() calls after the context get created or send_context_changed_event() has been called :(
Generally what we see happening when debugging programs on a target is:
0. User adds breakpoint on source line: the tcf-agent can't resolve the
line, the breakpoint is not planted
1. The program starts: a new context is created, the target is stopped.
2. The symbol file is loaded on the new context: the breakpoints are
"replanted" by the agent. This time the address for the line is resolved
and the user breakpoint is planted on the processor.
In the case of a breakpoint on an address, the breakpoint gets directly
planted after the context creation event.
Hope this helps,
- Christophe
If you want I could provide my implementation of context-sib.c but I must warn you that this file is quite messy at the moment since I try to break it all down from context-win32.c. ^^
2. call iterate_breakpoints() (at the moment the only way for me to obtain file:lineNr from bps)
3. call RunUntilBreakpointHit()
...
I have one little guess left..
This is my cpu_bp_plant():
int cpu_bp_plant(ContextBreakpoint * bp) {
bp->access_types = 0;
return CLIDevice_PlantBreakpoint(bp->address);
}
Could it be possible that I have to store the whole ContextBreakpoint struct and not just its address and remove the breakpoints according to their struct they belong? I did not try this out, it just came to my mind right now.
Well more or less you should probably keep your own mapping between
ContextBreakpoint * bp and your internal structure (if you have some).
Hm, basically I have an internal structure but I didn't expect that the agent would remove breakpoints right after they have been added. I might refactor this part later on but I think the agent shouldn't do that anyway like this.
As for changing the ContextBreakpoint access_types value I don't think
you should do that. This may be what causes the dirty flag!
Okay, I did remove this line.
I wonder .. do a lot of people have problems like I have? :D
Well debuggers are generally complex. The part we had more issues with
and that took some time to iron out (most of) the bugs was the run
control. (I'm working on the Simics debugger which is a simulator
offering reverse execution and debugging capabilities.)
I must confess that I am not logging a lot at the moment. But I think the TCF trace for now should be enough since I can see clearly in what order the events were happening etc.
Thank you very much for your help!
Stefan
Best regards,
Stefan
Attachment: My version of cpudefs-mdep.c
I really have no idea why this is the case and which event causes this behaviour ..
Best regards.
Stefan
Please Note that my agent does not communicate with the device directly instead talks to another server that is already capable of doing so.
Thank you and best regards,
Stefan Falk
-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Stefan.Falk@xxxxxxxxxxxx
Sent: Friday, May 16, 2014 8:47 AM
To: tcf-dev@xxxxxxxxxxx
Subject: [tcf-dev] Problem planting breakpoints
Hi and sorry for my third E-Mail today but I seem to have a major issue with the way how breakpoints are set and removed.
Like I said a few times already, all I got is a function CLIDevice_RunUntil(int[] breakpoint_address) to set breakpoints and run my device under debug.
Therefore I call iterate_breakpoints() to collect all file locations and map them to their actual memory addresses.
My problem is still that after the program reaches a breakpoint, the TCF Agent begins to "plant" breakpoints. The problem isn't that by doing so cpu_bp_plant() gets called and therefore CLIDevice_PlantBreakpoint() gets called, the problem is that immediately after that cpu_bp_remove() is getting called.
I have no idea why this is happening. All I can tell so far is that InstructionRef ref->cnt in validate_bi_refs is zero for some reason the "dirty" flag of BreakInstruction is TRUE gets set there. Therefore it gets deleted later on.
I'm really really stuck here. I've tried the whole day to find out what is wrong but I really don't understand the underlying reason why the agent wants to remove my breakpoints ..
Thanks for your help.
--
Stefan Falk
Infineon Technologies Austria AG
Trainee
Automotive Sense and Control
Component Verification
Tel: +43 (0)5 / 1777 - 5439
Email: stefan.falk@xxxxxxxxxxxx<mailto:stefan.falk@xxxxxxxxxxxx>
"Aim above the mark to hit the mark." - Ralph Waldo Emerson
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tcf-dev
