| Re: [tcf-dev] Investigating TCF Agent Port to RTEMS |
Hi Joel,
> I don't know how to forward both TCP and UDP. If I understand things, that means the commands work but not the discovery.
It’s OK, discovery is for user convenience only.
> For RTEMS (like VxWorks), I had to modify main.c to be main_tcf() so it can be invoked from the RTEMS Shell.
You can also add this in config.h:
#define main(argc, argv) main_tcf(argc, argv)
Someday, when everything works and stable, you can consider making changes in the main repo and pushing upstream.
Until then, it is better to work in a separate sandbox.
> I had to add main.o to the libtcf.a since it is a function not a main().
I’m not sure what you mean. main() is a function.
The only reason to create libtcf.a is to allow linker to link only modules which are actually used.
It is only an optimization.
> #define USE_canonicalize_file_name 0
> #define USE_strlcpy_strlcat 1
> #define USE_getauxval 0
This macros allow the agent to use certain functions from libc.
Proper values depend on libc version.
> #define USE_enum_ptrace_request 0
Since you don’t have ptrace, this should be irrelevant.
> I had to add stubs for grantpt(), unlockpt(), ptsname(), and posix_openpt().
These are used by the Processes service.
You can either disable the service for now, or develop an implementation similar to VxWorks version of the service.
Eventually you will want this service - it allows to start target threads remotely.
> Even better would be some tcf client scripts that show things like the initial interaction and fetching registers, etc.
You can connect from Eclipse now.
Of course, Eclipse views will be empty until you replace stubs with something that returns useful data.
I would start with implementing the list of target threads (aka Contexts) - they will show up in the Debug view.
Then, implementing run control (context_stop, context_resume, etc.) will enable run control buttons in Eclipse.
Implementing get_reg_definitions, context_read_reg, context_write_reg will populate the Registers view.
Then memory access, few other things, and you are done.
_______________________________________________
Regards,
Eugene
From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Joel Sherrill
Sent: Friday, October 30, 2020 3:07 PM
To: TCF Development <tcf-dev@xxxxxxxxxxx>
Subject: Re: [tcf-dev] Investigating TCF Agent Port to RTEMS
CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
On Fri, Oct 30, 2020 at 2:57 PM Eugene Tarassov <eugenet@xxxxxxxxxx> wrote:
Hi Joel,
To make long story short, I’ve committed a script, which creates a git repo for agent porting project.
Well I'm going to follow up with a longer story. :)
The repo is an example of how to start such project.
Run the script:
org.eclipse.tcf.agent/agent/bin/create-agent-project -n rtems
Then look into tcf.agent.rtems/system/rtems/tcf/context-rtems.c.
It contains stubs of all functions you need to implement using debug APIs available in RTEMS.
That certainly is appreciated. It changed my perspective on how the port got built. I had been adding files to the main repository. I now have an RTEMS executable which has more services than it did before:
$ ./obj/GNU/Linux/x86_64/Debug/client
> peers
Peers:
> connect
Connection established with TCP:127.0.0.1:1534
> services
Remote services = [ZeroCopy, Diagnostics, Profiler, Disassembly, DPrintf, PathMap, Streams, Expressions, FileSystem, ProcessesV1, Processes, SymbolsProxyV2, SymbolsProxyV1, StackTrace, Registers, MemoryMap, Memory, Breakpoints, RunControl, ContextQuery, Locator]
I think the peers command cannot find the RTEMS system because I am running the Zynq BSP on Qemu and I don't know how to forward both TCP and UDP. If I understand things, that means the commands work but not the discovery.
But I am thrilled and quite appreciative.
Some feedback on what I did to what was instantiated in case you care for the future.
1. I added an include $(MAKE_INC) since that is where I am putting BSP specific settings. It is above the include of Makefile.inc.
2. For RTEMS (like VxWorks), I had to modify main.c to be main_tcf() so it can be invoked from the RTEMS Shell. That's the only change to the primary tcf repo source so far but there are warnings I need to look at.
3. I had to add main.o to the libtcf.a since it is a function not a main(). I assume VxWorks does something similar since they rename it to tcf().
4. I have an rtems_tcf executable which links in an RTEMS configuration with shell and network configuration so there is a bit of change for a different executable.
5. For config.h, I added these which I discovered via check-c-lib:
// detected by check-c-lib
#define USE_canonicalize_file_name 0
#define USE_enum_ptrace_request 0
#define USE_strlcpy_strlcat 1
#define USE_getauxval 0
I will happily admit that I trusted the output of check-c-lib and didn't investigate further.
6. I had to add stubs for grantpt(), unlockpt(), ptsname(), and posix_openpt(). I have not investigated this and don't know if there is an ifdef I need to set to avoid them.
This is a great starting point. Is there anything which gives insight into the how the methods should work or how they related to GUI views?
Even better would be some tcf client scripts that show things like the initial interaction and fetching registers, etc.
I'm sorry to have to ask questions but there are a lot of details to get the mapping right.
Thanks. This really is a big leg up.
--joel
HTH.
Oh it did!
Regards,
Eugene
From: tcf-dev-bounces@xxxxxxxxxxx <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Joel Sherrill
Sent: Thursday, October 29, 2020 2:38 PM
To: tcf-dev@xxxxxxxxxxx
Subject: [tcf-dev] Investigating TCF Agent Port to RTEMS
CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
Hi
I am starting to work through porting the TCF Agent to RTEMS. RTEMS is a single process, multi-threading open source RTOS. Executables are usually statically linked and the TCF Agent is running as a thread. I have pushed through the build system and gotten the Agent running enough for the portable services to work. By that, I mean those services that compiled out of the box. This is enough to have the FileSystem service working.
I am now feeling a bit overwhelmed with a list of services that have names that seem like I want to enable them but I don't know which are the minimum required. I am sure we don't want any that resolve symbolic information on the target and SysMonitor that depends on /proc which RTEMS does not have.
Which services should I focus on?
I started on RunControl which quickly got me into addressing context area definitions and ptrace(). I don't see any other way to implement this in the git source, so my current plan is to implement a minimal ptrace() for RTEMS.
What needs to be done to present a single process and multiple threads via the agent?
Is there any guidance on which Services support which perspectives in Eclipse? How can I know when I have done enough to make a specific perspective work?
Sorry to ask so many questions. There is a lot of magic to decipher and adapt. :)
Thanks.
--joel
RTEMS
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tcf-dev
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tcf-dev