tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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


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)



Christos Zoulas <> wrote:
>In article <>,
>Maxime Villard  <> wrote:
>>This isn't correct, with USER_LDT the 32bit LWPs may have non-default segregs,
>>besides it is really dumb to mix 32 and 64bit code, part of the reasons why
>>I dropped the thing
>Yes, it is still missing the check that the compat_netbsd32 function had.
>Before you disabled the code it was possible to debug a 32 bit process
>with a 64 bit debugger. This is still useful because trying to debug a
>32 bit process with a 32 bit debugger on a 64 system is extremely difficult
>to get it right because the 32 bit debugger needs to know somehow that it
>is running on a 64 bit system in order to mangle the paths properly and
>load the appropriate shared libraries.
>I think that the choice if we are going to let this work or not does not
>belong to the opinion of a single person, but to the developer base of
>NetBSD or the core group.

Home | Main Index | Thread Index | Old Index