Help needed setting up git/github GhidraDev Processor project based on fork of an existing Ghidra Processor

[hippietrail]

I've been working on #487 to add A-Line trap support to Motorola 680x0 processor support. I've made a badly-set-up Ghidra repo: https://github.com/hippietrail/Motorola68000ALine

Since there's no way in Ghidra to derive a new processor in an extension from an existing built-in processor, it seems the "proper" way to tackle this, at least in the experimental stages is like this:

1. Start a new GhidraDev "Ghidra Module Project" with just a processor in it.
2. Git-fork just the current 68000 processor inside the GhidraDev project, probably at the data directory level above languages/68000.ldefs etc.

This way the forked 68k processor will have the back-history and will also be able to pull in new changes to avoid getting out of sync.

I tried to set up my project listed above but struggle enough with more basic things in git and this seems doable but advanced. I've obviously done it wrong.
When I've made further changes to the Sleigh files I'm unable to push them and the outer (GhidraDev) and inner (68000) repos seem to be out of sync with each other re previous changes that I thought were working fine.

If anyone can guide me on the correct way to set this up, or who can confirm that this is not actually possible with Git after all, it would be very much appreciated. Maybe the proper way is totally different? If it can't be done in a way where the inner 68000 repo is working, then I'll just cut and paste it in, but that would be a shame.

[ryanmkurtz]

Git-fork just the current 68000 processor inside the GhidraDev project, probably at the data directory level above languages/68000.ldefs etc.
This way the forked 68k processor will have the back-history and will also be able to pull in new changes to avoid getting out of sync.

You can't do this. I'd just manually drop whatever processor files you want into your repo, and call it a day.

[hippietrail]

Thanks. At least I know not to waste time down a dead-end rabbithole!
I actually have a proof of concept of it working directly in the current 680x0 Sleigh files by adding two new variants much like the ColdFire variant but introducing just one new instruction, in two variants.

Is that the sort of thing I should just do a PR of already or is there another way to propose code that's not mature enough for a PR yet?

[ryanmkurtz]

GitHub has a "Draft" PR feature, which indicates it's not quite production ready, but still allows for code review.

[hippietrail]

Ah I just noticed that myself a few hours ago and thought I'd go ahead and try it. Trying to gather some more details on how other platforms used these traps after seeing how they need different handling on Mac vs Lisa.

[hippietrail]

#7126