Re: [patch] Fix a glitch in debugging 32-bit process with 64-bit GDB.

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

On Sat, Dec 13, 2008 at 8:01 AM, Joel Brobecker <brobecker@adacore.com> wrote:

> > - leave GDB broken and wait for newer glibc :(
>
> I'm just realizing that this might be a very very visible problem,
> if most offsets are negative. Is that the case?

Now that you've mentioned it, I see that there is a trivial test case:

int bar(int x) { return x; }
int foo(int x) { int y = x; return bar(y); }
int main() { return foo(0); }

gcc -gstabs -m32 t.c && gdb64 -q ./a.out

(gdb) b bar
Breakpoint 1 at 0x8048303: file t.c, line 1.
(gdb) r

Breakpoint 1, bar (x=0) at t.c:1
1	int bar(int x) { return x; }
(gdb) up
#1  0x0804831f in foo (x=0) at t.c:2
2	int foo(int x) { int y = x; return bar(y); }
(gdb) info locals
y = Cannot access memory at address 0xffffd954


> > - do sign extension, but only for N_LSYM and N_PSYM symbols as
> >  a heuristic.
>
> It seems to me that this should work without negative effect
> (we have to be a little careful because there is a 64bit stabs
> extension on Tru64).

AFAICT, Tru64 goes through ECOFF reader in mdebugread.c, and so
wouldn't be affected by a change to dbxread.c

> After all, values for these types of symbols
> are always offsets to some location inside a frame, and I can't see
> a frame being that big.

Especially in a 32-bit executable ...

> > - pre-scan the objfile to determine highest link address, and
> >  do sign extension if that address is (well) below 0x80000000
>
> Seems too much work, IMO.

Right.

So here is a 3rd attempt.

Thanks,
--
Paul Pluzhnikov


2008-12-12  Paul Pluzhnikov  <ppluzhnikov@google.com>

        * dbxread.c (read_ofile_symtab): Sign-extend 32-bit N_LSYM and
        N_PSYM STABS values for 64-bit GDB.

Attachment: gdb-1526195-20081212.txt
Description: Text document