Re: re-enabling debugging of 32 bit processes with 64 bit debugger

[<Paul.Koning%dell.com@localhost>]

> On Jun 28, 2019, at 4:44 PM, Christos Zoulas <christos%zoulas.com@localhost> wrote:
> 
> 
> [EXTERNAL EMAIL] 
> 
> 
> Background:
> 
> Max disabled the 32 bit code paths in process_machdep.c and matchdep.c 
> so trying to debug 32 bit processes from a 64 bit debugger. From his commit
> message I think this was not intentional:
> 
>    revision 1.36
>    date: 2017-10-19 05:32:01 -0400;  author: maxv;  state: Exp;  lines: +35 -0;  commitid: 0ZqTTwMXhMd40EbA;
>    Make sure we don't go farther with 32bit LWPs. There appears to be some
>    confusion in the code - in part introduced by myself -, and clearly this
>    place is not supposed to handle 32bit LWPs.
> 
>    Right now we're returning EINVAL, but verily we would need to redirect
>    these calls to their netbsd32 counterparts.
> 
> I've been asking him privately to re-add the code (I even gave him a patch),
> but after not responding for a few days we had the exchange (appended below)
> which leads me to believe that he does not believe the functionality is useful.
> 
> I would like to have this functinality restored because as I explained below
> it is easier to use a 64 bit debugger on a 32 bit app (for various reasons),
> plus I want to add some unit-tests to make sure we don't break it in the
> future, since it is required for mips64 right now. It is harder to add
> a new testing platform than doing this on amd64.
> 
> What do you think? SHould we make the code work like before? Or this is
> functionality that we don't want to have because it is "dumb"? (I think
> that Max here means that it adds complexity and it could be dangerous,
> but I am just guessing)

I'm baffled that this is even debatable.  The system supports running 32 bit code in a 64 bit system.  Obviously you must be able to debug such processes.

I suppose you could claim it would suffice to build two debuggers, one for each target.  But that makes no sense.  All the toolchains are multi-architecture: you can compile for 32 or 64 bit at the drop of a switch, and you can link all that with a single toolchain. GDB has supported multi-arch for a long time (in fact, not just multiple width but entirely different ISAs from a single image).  So it would be thoroughly strange to say that this sort of basic flexibility and user-friendliness is to be abandoned here.  And why would NetBSD want to regress like that?  Other platforms do this as a matter of course; it seems odd for NetBSD even to consider looking technically inferior in this respect.

	paul