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

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Sat, 29 Jun 2019 at 16:04, Christos Zoulas <christos%astron.com@localhost> wrote:
>
> In article <CAJeAr6vOWxv4ZxspYNMDeuP0U=ZcCFACPsBMOZ-4xguf54njTg%mail.gmail.com@localhost>,
> Andrew Cagney  <andrew.cagney%gmail.com@localhost> 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
>