Re: [hatari-devel] Upstream / downstream code in Hatari

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi Andreas,

Do you (or Thomas) have some proposal on the coding.txt update?

(Your list was too long to be added as-is I think.)

On 22.8.2025 8.15, Andreas Grabher wrote:
> > You don't have any need for profiling or debug symbols and backtraces (which needs both of those functionalities)?
> >
> > I don't think profiler has anything Atari specific except handling and printing of memory area limits, which is very small part of it.
> >
> > It needs symbols though, but while binary symbol formats are Atari specific, the ASCII one (used with profile post-processor) is not, and I think you can just ignore (ifdef out) rest.
> I don‘t use profiling and also the debugger is not really in use by me. Therefore I did not invest too much time into that part. But I would like to keep the option to add this later.

Do NeXT ROM and programs in general include debug symbols, or are their 
symbol names / addresses otherwise available?


Note that my own main use-case for profiling is NOT optimizing m68k 
software, but understanding better how it works, things like:

* How the program ended calling some specific subroutine => backtrace

* What code program is running [1], e.g. when it freezes; are interrupt 
handlers being called?

[1] Profiler provides me call-count annotated disassembly of just the 
instructions that were run since debugger was last invoked, and it works 
both for CPU & DSP. That's much easier to read than CPU/DSP trace, as it 
outputs *much* less data.

While symbols make that info easier to read, it's somewhat useful also 
without them.


[...]
> > Applying each relevant commit from Hatari sources by hand, sounds rather laborious.
> >
> > But with this large set of differences, handling git rebase conflicts could also be quite a lot of work, especially when list of change commits stacked on top of the upstream code grows (so at some point it would be more work unless those changes could be upstreamed).
> That is exactly the problem. Therefore I am interested in keeping the differences small. It is not that big of a problem if a file contains Atari specific parts concentrated at the bottom and common parts on top. But it gets annoying if everything is mixed up and new dependencies are added.

FYI: I pushed your paths.c changes to repo.


> > What version control you're using for Previous code?
> I use subversion.

Have you considered switching to Git / is something blocking it?

IMHO subversion is not really better than CVS (with rsync), I especially 
remember its branch management being rather horrible, wheres with Git, 
it's trivial to create/delete/rename/manage branches (which along with 
rebasing, really helps maintaining changes to other SW).

I suspect that nowadays Git does better every feature that Subversion 
provides, probably any of the still supported other distributed versions 
systems does... :-)


	- Eero