Re: [tcf-dev] Investigating TCF Agent Port to RTEMS

[Joel Sherrill <joel@xxxxxxxxx>]

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