On Fri, 2019-06-28 at 16:44 -0400, Christos Zoulas wrote: > 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 also interested in this since it's going to affect LLDB long term. However, I am not sure how it should work exactly, especially in context of registers. AFAIU the old behavior was that ptrace() used 64-bit data types, and padded unused parts. I suppose this could be somewhat convenient (since you have less variety to account for) but at the same time rather weird. And in the end, debuggers would have to know how to correctly truncate those registers, and skip the unused ones. The alternative would be to reuse compat32 codepaths more, effectively switching to 32-bit data types. However, this would mean that debuggers would have to switch between structures passed to ptrace() based on whether the tracee is 32- or 64-bit. -- Best regards, Michał Górny
Attachment:
signature.asc
Description: This is a digitally signed message part