First contribution

[C47D]

Hi @mubes , I would like to start a list of activities, kind of 'first contributions' tasks, to get familiar with the orbcode tooling.Do you (or folks) have such list?

[mubes]

Hiya, I don't have a specific list at the moment, but I can think of a number of 'nice to haves'. I will edit this list as 'reply 1' as others add material so, at least in the short term, it's a useful list. These are in no specific order;

1. Extend the CI testing to perform regression tests: When something gets changed there is always the possibility that we break something that was previously working. It would therefore be useful if we could have some basic tests that we run during the CI to ensure that at least the gross functionality is still operational. I would expect this would be done by 'replaying' captured files into the utilities (via the orbuculum -f xxx mechanism or direct file feeding into each utility) and then doing a diff on the resulting output.

2. Better project-wide configuration mechanisms. When the tooling is being used on a project then it's configuration doesn't really change, so it would be nice if all of the tools had the option to take configuration from a .orb file or similar in the root directory of the project. Current thinking is that this should be TOML based.

3. Multi-channel orbcat. It would be nice to be able to switch orbcat channels on and off in combination. The idea would be that when a capture has been performed then individual channels in the orbcat can be switched in or out of the flow to bring more or less information into view.

4. Graphics! All the utilities are currently text based. Some people like graphics. It would be nice to be able to offer graphical front ends for the utilities. I would expect they would still run in the same way, but be presented via the nicer UI if folks want that. Some utilities already have some limited capability for this (e.g. the JSON output options on orbtop).

5. Richer orbtop. Integrating orbtop and ncurses would allow users to be able to 'move around' in the loading views to see dynamically where the time is being spent; By file, by function, by line or by assembly instruction. This isn't as painful as it sounds...it's mostly applying the sio.c principles that are used in orbmortem to orbtop.

6. Execution markup from source or PAC file. There is information in the elf and in PAC files that we can use to decorate the execution records to make it more informative. The obvious low hanging fruit here is the interrupt vectors in orbtop, but I think there are plenty more. If we can extract that information we can give a richer record of what the target was doing.

I think that's a reasonable starting list, but I'd love people to make addition suggestions either in reply or via the Discord so we can extend this.