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: nvmm: change the api
On 30.06.2019 11:30, Maxime Villard wrote: > Le 05/06/2019 à 21:26, Kamil Rytarowski a écrit : >> On 05.06.2019 08:08, Maxime Villard wrote: >>> I intend to change the NVMM API in order to reduce the data >>> movements. The >>> patches are available here [1]. >>> >> >> This looks good and it will make the interfaces simpler. >> >> Could we merge the demo example into /usr/share/examples/nvmm ? >> >> https://www.netbsd.org/~maxv/nvmm/nvmm-demo.zip >> >> It will be easier and quicker to navigate it on disk easier whenever >> needed. > > I didn't feel like consuming disk space It's strange as we got some real outdated, incomplete content in src/share/doc and it would be much more valuable to replace it with something that is relevant and useful. BSD was advertised as it's sufficient to install it and browse it without internet access in order to start coding.. signature.asc Description: OpenPGP digital signature
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: nvmm: change the api
Le 05/06/2019 à 21:26, Kamil Rytarowski a écrit : On 05.06.2019 08:08, Maxime Villard wrote: I intend to change the NVMM API in order to reduce the data movements. The patches are available here [1]. This looks good and it will make the interfaces simpler. Could we merge the demo example into /usr/share/examples/nvmm ? https://www.netbsd.org/~maxv/nvmm/nvmm-demo.zip It will be easier and quicker to navigate it on disk easier whenever needed. I didn't feel like consuming disk space
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
