Re: [tcf-dev] Problem planting breakpoints

[<Stefan.Falk@xxxxxxxxxxxx>]

>> 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 :(

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