> Date: Wed, 30 Apr 1997 21:59:33 +0200 (MET DST)
> From: Matthias Drochner <drochner@zelux6.zel.kfa-juelich.de>
> 
> I'm just playing with remote kernel debugging on
> a 68040 board. (from an Ultrix host)
> gdb (even the version in the NetBSD souce tree,
> from a look at the source) uses trap #1 for
> breakpoints on remote targets.
> The NetBSD ports, as far as I can see, assume
> sigreturn() there and use trap #15 for breakpoints.
> How could this ever work? Or am I missing
> something?
> (After I changed it, breakpoints didn't cause
> panics anymore.)
> 
> best regards
> Matthias

I'm glad you brought this up.  It appears that there has been some
confusion about which m68k trap numbers are used for what on which
systems.  After researching the subject, here is what I found:

	trap 0:
		All*: system call
		   * (NetBSD, SunOS, HUPX)
	
	trap 1:
		NetBSD: sigreturn
		SunOS: sigreturn
		HPUX: user breakpoint
	
	trap 2:
		NetBSD: user breakpoint
		SunOS: user-mode cache flush
		HPUX: sigreturn
	
	traps 3-11:
		not used
	
	trap 12:
		NetBSD: cachectl (user-mode cache flush)
	
	traps 13,14:
		not used
	
	trap 15:
		NetBSD: kernel breakpoint
			(maybe user breakpoint also?)
		SunOS: user breakpoint
		HPUX: (not used?)

I would prefer if we could switch to the much more common choice of
trap 15 for user-mode breakpoints instead of trap 2 as gdb uses now.
It is quite easy for the breakpoint trap handler to determine if the
trap was from user or supervisor mode and call the right handler.  If
that bothers people, we could follow the SunOS lead and use trap 14
as the kernel breakpoint, but I see no reason to do that.

We could always retain trap 2 handling for a while in case someone
has an old copy of gdb they want to use, but I doubt many people
would scream if we told them they need to update gdb.

Note that trap 2 is used by the SunOS dynamic linker to flush the
instruction cache after it has modified the calling program, and
its handler should be as fast as possible to avoid poor startup
performance for SunOS dynamically linked executables.  If trap 2 is
no longer used for NetBSD user breakpoints, and if you are not
supporting HPUX emulation (and most ports do not) then the trap 2
handler can safely assume that an "icache flush" is the right thing
to do without bothering to check the emulation type.

Does this sound OK?

Gordon