| Re: [tcf-dev] TCF architecture , support for OCD/JTAG questions |
|
Hi Dan,
> but it is not possible find something as "TCF for dummies" :) ... ) Welcome ! I understand your concerns. :-). Once you understand something, don't hesitate to explain it on the tcf-dev list. > 1. Does TCF agent support cross compilation , looking to the makefiles i am not see such support , so what i am lost ? Yes. Well, you'll probably have a workout your own build rules but the code is designed to run on a target. There is a machine subdirectory. Below, each architecture. cudepfs defines the list of register disassembler is a disassembler dwarfreloc is a Dwarf debug infos relocator. stack-crawl is a stack crawler. What we do is have build rules that "overrides" some defines and "overrides" some files too. For instance, look HOOKS. By default these hooks are empty : do {} while(0) Our build system "overrides" them with our content. This way, you can "tweak" the TCF behavior. So you can create your build rules, add your files to define your own service, if you need to. 2> or to the host (TCF server) is it mean that possible configure some part of the agents services (back trace for example) to run on the host and some part leave on the target yes. agent will run on target server will run on the host. agent and server do have a config.h. In there, you can define if a service is present (1) or not (0). You can have what we call a TCF chain : tcf-server <---> tcf-logger <---> target. Understand too that the tcf-server can call a service on target but the target can also call a service in the tcf-server. Both way : Powerful but you can quickly get lost too :-) 2> Is it will be transparent or need some additional changes. How make it work? Yes and no. You need a "proxy" for this. For instance, take a look at linenumbers_proxy.c Imagine the breakpoint service is running on target. At some point, it wants to call "line_to_address". But the symbols are handled on the host side. line_to_address in the linenumbers_proxy.c will call the "LineNumber" service on the host by using protocol_send_commands. The linenumber service is running on host side. It means: Host is using linenumbers.c Target is using linenumbers_proxy.c 3> It is difficult understand the flow looking to the code. Yes it is. You need to read my ACPM document there: https://bugs.eclipse.org/bugs/show_bug.cgi?id=425794 I'm not saying it's 100% correct, but it should give you an overall idea. My main advice would be not follow the code with a debugger step by step. ACPM makes it very difficult to follow by stepping. I prefer printf ! To understand the flow of execution, I'm currently writing a small tool in my spare time: https://github.com/XavierP56/PetitPoucet (I haven't worked on it since 3 months, and it's a little harsh to setup). Logs aren't easy to understand either especially when you have a long tcf-chain. Place some breakpoints where you send commands (protocol_send_command) and place breakpoints in the various callback. a symbol ID is actually very long so by reading the log, you have difficulty figuring out what's wrong. Part of ID the DIE number (the various entries provided by readelf -wi). Look id2symbol and symbol2id. From an id, it can reconstruct a symbol object. > We are looking to move the JTAG from GDB to TCF debugger. Is it possible ? Yes should be. Can you please point me to what should be changed on the both sides (JTAG side and TCF side for make it work ? Look for context_mem_read / context_.... These context_ apis are the best places to look at. The directory system will contain these context_api. Look for instance there: org.eclipse.tcf.agent/agent/system/VxWorks/tcf/context-vxworks.c Look for context_plant_breakpoint. Hope it will help a little. Best Regards, Xavier. On 06/09/2015 16:28, dan wrote:
|