Re: re-enabling debugging of 32 bit processes with 64 bit debugger
https://www.netbsd.org/~christos/ptrace32.diff
looks good to me, however the function should be called something like
cpu_mcontext32from64_validate, to make it clear that it's just
cpu_mcontext32_validate with a 64bit structure
and in process_write_regs(), add {}s in the else too
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
In article <19705.1561931...@splode.eterna.com.au>, matthew green wrote: >i fully support making debugging work. that means debugging >32 bit apps on 64 it kernels, and also, eventually?, using >a 32 bit debugger on 64 bit kernel. > >these are all real-world cases people use and expect to work. How about this patch? https://www.netbsd.org/~christos/ptrace32.diff christos
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On 01.07.2019 17:06, Andrew Cagney wrote: > On Mon, 1 Jul 2019 at 10:06, Kamil Rytarowski wrote: >> >> On 01.07.2019 16:01, Christos Zoulas wrote: >>> In article , >>> Michael van Elst wrote: chris...@astron.com (Christos Zoulas) writes: > We can fill them completely with 0 as we pad with 0 the 32 bit > part of the 64 bit registers that does not exist in a 32 bit > process. The corefile pretends to be a 32bit file, so the register section should probably be similar to a coredump of a 32bit system. N.B. two registers were not zero padded, a temporary and the 'hi' register. So I don't think there is padding (or truncating) done. >>> >>> I have not looked at the core file, I was referring to what should be >>> returned by PT_GETREGS in the 64 bit tracer 32 bit tracee case. >>> >>> christos >>> >> >> From a debugger point of view, native struct reg, that is on the kernel >> side adapted (truncated registers) for 32bit tracee > > Right, a 64-bit ptrace() interface must return 64-bit structures. I'd > start with that, test it and see what breaks. > > However, beyond that, the main thing is for all parties to play nice. > In general: > - when reading values the debugger is converting 64-bit raw values to > the 32-bit ISA > - when storing values the debugger should be writing to the full > 64-bit ISA register > - and the kernel should kindly do the same thing > But wait, and this is where everyone gets to play nice. There's > likely some obscure edge case where the kernel needs to leak a full > 64-bit register value so that some feature works - perhaps h/w debug > registers, perhaps not. > Debug Registers use the same registers and almost the same bits since 80386. Control and Status register is meaningful for least significant 32 bits only. We just need to validate that address in DR0-4 is within the 32bit address space. > Andrew > signature.asc Description: OpenPGP digital signature
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On Mon, 1 Jul 2019 at 10:06, Kamil Rytarowski wrote: > > On 01.07.2019 16:01, Christos Zoulas wrote: > > In article , > > Michael van Elst wrote: > >> chris...@astron.com (Christos Zoulas) writes: > >> > >>> We can fill them completely with 0 as we pad with 0 the 32 bit > >>> part of the 64 bit registers that does not exist in a 32 bit > >>> process. > >> > >> The corefile pretends to be a 32bit file, so the register > >> section should probably be similar to a coredump of a > >> 32bit system. > >> > >> N.B. two registers were not zero padded, a temporary and the 'hi' > >> register. So I don't think there is padding (or truncating) > >> done. > > > > I have not looked at the core file, I was referring to what should be > > returned by PT_GETREGS in the 64 bit tracer 32 bit tracee case. > > > > christos > > > > From a debugger point of view, native struct reg, that is on the kernel > side adapted (truncated registers) for 32bit tracee Right, a 64-bit ptrace() interface must return 64-bit structures. I'd start with that, test it and see what breaks. However, beyond that, the main thing is for all parties to play nice. In general: - when reading values the debugger is converting 64-bit raw values to the 32-bit ISA - when storing values the debugger should be writing to the full 64-bit ISA register - and the kernel should kindly do the same thing But wait, and this is where everyone gets to play nice. There's likely some obscure edge case where the kernel needs to leak a full 64-bit register value so that some feature works - perhaps h/w debug registers, perhaps not. Andrew
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On 01.07.2019 16:01, Christos Zoulas wrote: > In article , > Michael van Elst wrote: >> chris...@astron.com (Christos Zoulas) writes: >> >>> We can fill them completely with 0 as we pad with 0 the 32 bit >>> part of the 64 bit registers that does not exist in a 32 bit >>> process. >> >> The corefile pretends to be a 32bit file, so the register >> section should probably be similar to a coredump of a >> 32bit system. >> >> N.B. two registers were not zero padded, a temporary and the 'hi' >> register. So I don't think there is padding (or truncating) >> done. > > I have not looked at the core file, I was referring to what should be > returned by PT_GETREGS in the 64 bit tracer 32 bit tracee case. > > christos > From a debugger point of view, native struct reg, that is on the kernel side adapted (truncated registers) for 32bit tracee. signature.asc Description: OpenPGP digital signature
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
In article , Michael van Elst wrote: >chris...@astron.com (Christos Zoulas) writes: > >>We can fill them completely with 0 as we pad with 0 the 32 bit >>part of the 64 bit registers that does not exist in a 32 bit >>process. > >The corefile pretends to be a 32bit file, so the register >section should probably be similar to a coredump of a >32bit system. > >N.B. two registers were not zero padded, a temporary and the 'hi' >register. So I don't think there is padding (or truncating) >done. I have not looked at the core file, I was referring to what should be returned by PT_GETREGS in the 64 bit tracer 32 bit tracee case. christos
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
chris...@astron.com (Christos Zoulas) writes: >We can fill them completely with 0 as we pad with 0 the 32 bit >part of the 64 bit registers that does not exist in a 32 bit >process. The corefile pretends to be a 32bit file, so the register section should probably be similar to a coredump of a 32bit system. N.B. two registers were not zero padded, a temporary and the 'hi' register. So I don't think there is padding (or truncating) done. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
In article , Michael van Elst wrote: >m...@eterna.com.au (matthew green) writes: > >>i fully support making debugging work. that means debugging >>32 bit apps on 64 it kernels, and also, eventually?, using >>a 32 bit debugger on 64 bit kernel. > >Can we prevent a 64bit kernel to dump 64bit registers for >32bit userland processes ? We can fill them completely with 0 as we pad with 0 the 32 bit part of the 64 bit registers that does not exist in a 32 bit process. christos
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
m...@eterna.com.au (matthew green) writes: >i fully support making debugging work. that means debugging >32 bit apps on 64 it kernels, and also, eventually?, using >a 32 bit debugger on 64 bit kernel. Can we prevent a 64bit kernel to dump 64bit registers for 32bit userland processes ? -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
re: re-enabling debugging of 32 bit processes with 64 bit debugger
i fully support making debugging work. that means debugging 32 bit apps on 64 it kernels, and also, eventually?, using a 32 bit debugger on 64 bit kernel. these are all real-world cases people use and expect to work. thanks. .mrg.
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On Sun, 30 Jun 2019 at 10:28, Jason Thorpe wrote: > > > > On Jun 30, 2019, at 6:46 AM, Andrew Cagney wrote: > > > > Things started to go down hill when the debugger developers decided > > that rooting around in the process to extract the memory map was "a > > good idea". After all, it too is likely been corrupted by the crashing > > program. > > > > There's /proc/PID/maps, there should be a PTRACE equivalent and it > > should also be dumped into the core file. > > Certainly, the ELF core files dumped by NetBSD have a PT_LOAD section for > each VM map entry, so the memory map information is already there. Right (with debugger magic filling in the missing but listed read-only segments). > Now, for mapped files, it doesn't record the path name like you get with > /proc/PID/maps, but that's something that could be fixed by having one or > more additional PT_NOTE sections where the note contains a PT_LOAD index to > file name mapping (with the path string being contained in the note). What ever the format it might as well be consistent between /proc, ptrace() and core dumps, and should accommodate variable length paths (unlike the current core file structure). Spewing /proc/pid/maps (actually, much of /proc/pid) as one or more notes into core file is a good starting point (and one known to work). Other formats are also valid. (I thought 9 had forked) > -- thorpej >
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On 30.06.2019 19:19, Jason Thorpe wrote: > > >> On Jun 30, 2019, at 10:15 AM, Christos Zoulas wrote: >> >> I think that our goal is be able to branch 9 with a gdb that works as well >> as 7 (since it is more broken in 8 because of the 64->32 breakage). > > Yah, that's fair... I just think we need to not lose sight of the bigger > picture so that we don't paint ourselves into a corner. > >> >> christos > > -- thorpej > Please just fix gdb 64bit for 32bit tracee support (actually on the kernel level) and leave the rest to pulling new gdb/lldb from upstream. Adding any ad-hoc core structs is imho premature as there are 10 more important things to fix/support (not listing there to not generate offtopic). We are aware about remote debugging and core debugging support and their needs, we are the only BSD out there with LLDB Remote Process Plugin and probably the first BSD in GDB soon. I already got gdbserver to build and run for NetBSD locally, but with stub support that still crashes early. signature.asc Description: OpenPGP digital signature
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
> On Jun 30, 2019, at 10:15 AM, Christos Zoulas wrote: > > I think that our goal is be able to branch 9 with a gdb that works as well as > 7 (since it is more broken in 8 because of the 64->32 breakage). Yah, that's fair... I just think we need to not lose sight of the bigger picture so that we don't paint ourselves into a corner. > > christos -- thorpej
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
I think that our goal is be able to branch 9 with a gdb that works as well as 7 (since it is more broken in 8 because of the 64->32 breakage). christos
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On 30.06.2019 18:34, Jason Thorpe wrote: > >> On Jun 30, 2019, at 9:12 AM, Kamil Rytarowski wrote: >> >> Rationale? It worked for me in compat32 mode... > > Not if you're debugging core files, right? Everything that works for > live-debugging on native also needs to work for introspecting core files. > And, in an ideal world, also works for live cross-debugging to a completely > different arch using a debug server. > Right, sysctl(3) is perfectly fine for alive processes, but for core(5) we might want something extra. > This isn't just about "32-bit binaries on a 64-bit platform"... we really > should be thinking about this as a general cross-debugging problem. > >> >> There is also r_debug.r_map to get the list of shared objects. >> > > -- thorpej > I'm just spawning gdbserver-aware support for NetBSD in GDB basically from scratch (no other BSD is there). I want to use GDB tests to validate ptrace(2) kernel layer.. Michal works on MD parts. There are still few milestones for us before getting there. signature.asc Description: OpenPGP digital signature
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
> On Jun 30, 2019, at 9:12 AM, Kamil Rytarowski wrote: > > Rationale? It worked for me in compat32 mode... Not if you're debugging core files, right? Everything that works for live-debugging on native also needs to work for introspecting core files. And, in an ideal world, also works for live cross-debugging to a completely different arch using a debug server. This isn't just about "32-bit binaries on a 64-bit platform"... we really should be thinking about this as a general cross-debugging problem. > > There is also r_debug.r_map to get the list of shared objects. > -- thorpej
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On 30.06.2019 17:38, Jason Thorpe wrote: > > >> On Jun 30, 2019, at 8:19 AM, Kamil Rytarowski wrote: There is kinfo_getvmmap(3) + sysctl(3) equivalent. >>> >>> But this really should work for cross-debugging as well. >>> >>> -- thorpej >>> >> >> Is it broken? > > If you're relying on sysctl, then yes... > > -- thorpej > Rationale? It worked for me in compat32 mode... There is also r_debug.r_map to get the list of shared objects. signature.asc Description: OpenPGP digital signature
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On Sat, Jun 29, 2019 at 08:03:59PM -, Christos Zoulas wrote: > In article > , > Andrew Cagney wrote: > > > >Having 32-bit and 64-bit debuggers isn't sufficient. Specifically, it > >can't handle an exec() call where the new executable has a different > >ISA; and this imnsho is a must have. > > It is really hard to make a 32 bit debugger work on a 64 bit system > because of the tricks we play with the location of the shared > libraries in rtld and the debugger needs to be aware of them. I don't buy that at all. Exposing the translation to a debugger is trivial and in most cases, it doesn't care about the lookup mechanism at all since it just asks the dynamic linker for the path names of the libraries anyway. Joerg
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
> On Jun 30, 2019, at 8:19 AM, Kamil Rytarowski wrote: >>> There is kinfo_getvmmap(3) + sysctl(3) equivalent. >> >> But this really should work for cross-debugging as well. >> >> -- thorpej >> > > Is it broken? If you're relying on sysctl, then yes... -- thorpej
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On 30.06.2019 17:15, Jason Thorpe wrote: > >> On Jun 30, 2019, at 8:06 AM, Kamil Rytarowski wrote: >> >> On 30.06.2019 15:46, Andrew Cagney wrote: >>> There's /proc/PID/maps, there should be a PTRACE equivalent and it >>> should also be dumped into the core file. >> >> There is kinfo_getvmmap(3) + sysctl(3) equivalent. > > But this really should work for cross-debugging as well. > > -- thorpej > Is it broken? signature.asc Description: OpenPGP digital signature
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
> On Jun 30, 2019, at 8:06 AM, Kamil Rytarowski wrote: > > On 30.06.2019 15:46, Andrew Cagney wrote: >> There's /proc/PID/maps, there should be a PTRACE equivalent and it >> should also be dumped into the core file. > > There is kinfo_getvmmap(3) + sysctl(3) equivalent. But this really should work for cross-debugging as well. -- thorpej
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On 30.06.2019 15:46, Andrew Cagney wrote: > There's /proc/PID/maps, there should be a PTRACE equivalent and it > should also be dumped into the core file. There is kinfo_getvmmap(3) + sysctl(3) equivalent. We touched a related code recently (r_debug in rtld) as there was introduced support in LLDB for it recently but for now we have higher priorities (like XSAVE in core(5) files). Once we will be done with more elementary things we intend to work on this debugging mode. signature.asc Description: OpenPGP digital signature
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
> On Jun 30, 2019, at 6:46 AM, Andrew Cagney wrote: > > Things started to go down hill when the debugger developers decided > that rooting around in the process to extract the memory map was "a > good idea". After all, it too is likely been corrupted by the crashing > program. > > There's /proc/PID/maps, there should be a PTRACE equivalent and it > should also be dumped into the core file. Certainly, the ELF core files dumped by NetBSD have a PT_LOAD section for each VM map entry, so the memory map information is already there. Now, for mapped files, it doesn't record the path name like you get with /proc/PID/maps, but that's something that could be fixed by having one or more additional PT_NOTE sections where the note contains a PT_LOAD index to file name mapping (with the path string being contained in the note). -- thorpej
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On Sat, 29 Jun 2019 at 16:04, Christos Zoulas wrote: > > In article > , > Andrew Cagney wrote: > > > >Having 32-bit and 64-bit debuggers isn't sufficient. Specifically, it > >can't handle an exec() call where the new executable has a different > >ISA; and this imnsho is a must have. > > It is really hard to make a 32 bit debugger work on a 64 bit system > because of the tricks we play with the location of the shared > libraries in rtld and the debugger needs to be aware of them. Yes and no. Things started to go down hill when the debugger developers decided that rooting around in the process to extract the memory map was "a good idea". After all, it too is likely been corrupted by the crashing program. There's /proc/PID/maps, there should be a PTRACE equivalent and it should also be dumped into the core file. > In retrospect it would have been simpler (and uglier) to have > /32 and /64 in all the shared library paths so that they would > not occupy the filesystem space, but even then things could break > for raw dlopen() calls, or opening other data files that are not > size neutral. HP/UX with Context Dependent Files and IBM/AIX with > Hidden Directories were attempts to a solution, but they created > a new dimension of problems. > > christos >
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On Sat, Jun 29, 2019 at 12:42:50AM +, paul.kon...@dell.com wrote: > 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 totally agree, this is a must. Some architectures making it a PITA to support properly is no excuse for not doing at least a best effort thing (besides I don't see how the x86 mess would not apply just the same to a "native" i386 debugger). Martin
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On Sat, Jun 29, 2019 at 2:04 PM Christos Zoulas wrote: > In article zccfacpsbmoz-4xguf54n...@mail.gmail.com>, > Andrew Cagney wrote: > > > >Having 32-bit and 64-bit debuggers isn't sufficient. Specifically, it > >can't handle an exec() call where the new executable has a different > >ISA; and this imnsho is a must have. > > It is really hard to make a 32 bit debugger work on a 64 bit system > because of the tricks we play with the location of the shared > libraries in rtld and the debugger needs to be aware of them. > In retrospect it would have been simpler (and uglier) to have > /32 and /64 in all the shared library paths so that they would > not occupy the filesystem space, but even then things could break > for raw dlopen() calls, or opening other data files that are not > size neutral. HP/UX with Context Dependent Files and IBM/AIX with > Hidden Directories were attempts to a solution, but they created > a new dimension of problems. > I came to a similar conclusion when I hacked FreeBSD rtld to grok the difference between hard and soft float on the same system at the same time. Warner
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
In article , Andrew Cagney wrote: > >Having 32-bit and 64-bit debuggers isn't sufficient. Specifically, it >can't handle an exec() call where the new executable has a different >ISA; and this imnsho is a must have. It is really hard to make a 32 bit debugger work on a 64 bit system because of the tricks we play with the location of the shared libraries in rtld and the debugger needs to be aware of them. In retrospect it would have been simpler (and uglier) to have /32 and /64 in all the shared library paths so that they would not occupy the filesystem space, but even then things could break for raw dlopen() calls, or opening other data files that are not size neutral. HP/UX with Context Dependent Files and IBM/AIX with Hidden Directories were attempts to a solution, but they created a new dimension of problems. christos
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
> > 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. Having 32-bit and 64-bit debuggers isn't sufficient. Specifically, it can't handle an exec() call where the new executable has a different ISA; and this imnsho is a must have. Andrew
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
> On Jun 28, 2019, at 4:44 PM, Christos Zoulas 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
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
On 28.06.2019 22:44, Christos Zoulas wrote: > 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) Personally I consider it as a mandatory functionality. Maya wrote ATF tests verifying this code path through GDB (64bit debugger, 32bit tracee). On 28.06.2019 22:51, Michał Górny wrote:> 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. We want to pass all structs in the format of debugger always (so 64bit in 64bit debugger). Otherwise we would need to do compat32 fixups in userland code in LLDB/GDB. This is done in Linux/GDB and considered as a bug that hurts badly (like siginfo struct fixups). So it means that our previous support was doing the right thing. We still need to do some magic on the debugger side (like picking FS/GS depending on the mode), but that is not a big problem. signature.asc Description: OpenPGP digital signature
Re: re-enabling debugging of 32 bit processes with 64 bit debugger
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 signature.asc Description: This is a digitally signed message part
