Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] Problem planting breakpoints

1. PROGRAMMING_SUCCEEDED gets raised

There you should see calls to cpu_bp_plant after the contexts get created right?

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

As for changing the ContextBreakpoint access_types value I don't think you should do that. This may be what causes the dirty flag!

If you need to keep private data, you can use the ext field.

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

Because of the asynchronous/event based nature of TCF, I very frequently had to rely on logging (read printf) to understand what was going on.

- Christophe

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



Back to the top