dwarf2read problem

dwarf2read problem

[Jason Merrill]

I've been working on implementing something akin to the stabs BINCL
optimization in dwarf2, using .linkonce sections to discard all but one
copy of the debug info for a given header, but gdb fails to grok what I'm
generating.

dwarf2 uses direct references between DIEs (debug info entries).  Within a
dwarf TAG_compilation_unit (CU), these references are usually via offsets
relative to the CU.  But dwarf2 also allows you to refer to another DIE via
an offset from the beginning of the .debug_info section; this allows you to
refer to DIEs in other CUs, for use in optimizations like the one I've been
working on.

dwarf2read.c in GDB currently works by reading in the CU for the symbol we
want and remembering all the DIE offsets within that CU for inter-DIE
references.  Unfortunately, if it encounters a reference to a DIE in
another CU, that's an offset that it doesn't know anything about, so it
fails with "Dwarf Error: Cannot find referent at offset xxx."

Any chance of getting this fixed soon?  There's a simple testcase (source
and Linux/x86/glibc 2.1 executable) at

  http://www.cygnus.com/~jason/ref.tar.gz

Thanks,
Jason
From davea@quasar.engr.sgi.com Thu Nov 18 20:21:00 1999
From: davea@quasar.engr.sgi.com (David B Anderson)
To: tpeng@metrowerks.com
Cc: binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Questions about GCC MIPS R5900's mdebug section
Date: Thu, 18 Nov 1999 20:21:00 -0000
Message-id: <199911190421.UAA63304@quasar.engr.sgi.com>
X-SW-Source: 1999-q4/msg00285.html
Content-length: 1170

>2. If the GCC MIPS compiler can't generate the .stab and
>.stabstr sections, is there any documentation or source file or dump tool
>that descibles the .mdebug section in detail? 

I hope there is better documentation, somewhere, but there is a
(rather old) description of mdebug  I wrote long ago on:

   http://reality.sgi.com/davea/objectinfo.html

Maybe it will help.  Maybe not.  Take a look.

   Shift click on the 'here' in 
   "one part of the old 32bit ABI for MIPS is the 
   mdebug debugging information 
   A postscript file with the only currently available
   description of this data is here (119Kbytes)."

The document says nothing about the stuff defined by SGI for
C++ (which I presume that gcc sort of follows: I did not
check).  Basically the idea there was to follow  a normal
stStruct stEnd is followed immediately
by stTag and the c++ set of things
followed by stEnd. So the C++ classes are described
twice (yuck).


Corrections/ flames to:
David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/
Y2K conversion simplified: Januark, Februark, March, April, Mak, June,
Julk, August, September, October, November, December.
From ian@zembu.com Thu Nov 18 23:23:00 1999
From: Ian Lance Taylor <ian@zembu.com>
To: tpeng@metrowerks.com
Cc: gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com, tpeng@metrowerks.com
Subject: Re: Questions about GCC MIPS R5900's mdebug section
Date: Thu, 18 Nov 1999 23:23:00 -0000
Message-id: <19991119030947.12480.qmail@daffy.airs.com>
References: <199911182224.QAA25319@Metrowerks.com>
X-SW-Source: 1999-q4/msg00286.html
Content-length: 1374

   Date: Thu, 18 Nov 1999 16:25:42 +0000
   From: Thomas Peng <tpeng@metrowerks.com>

   1. Is there
   a way to force the GCC MIPS compiler to emit the .stab and .stabstr
   sections instead of the .mdebug section? Based on my knowledge, it looks
   like GCC is emitting stabs and the assembler is transforming that into
   .mdebug section. Shall we build GAS for MIPS with or without .mdebug stabs
   conversion disabled? if possible, many thanks for your suggestions in
   advance! 

It's pretty easy to convert the assembler to .stab/.stabstr.  However,
I think that gcc by default then generates stabs entries which don't
quite work, although that might be easy to fix.  I don't remember the
details, unfortunately.

   2. If the GCC MIPS compiler can't generate the .stab and
   .stabstr sections, is there any documentation or source file or dump tool
   that descibles the .mdebug section in detail? 

I don't know of any documentation on stabs smuggled in ECOFF.

Fortunately, when using stabs debugging, you don't really have to know
the .mdebug section in detail.  For an example of reading stabs in
.mdebug, see _bfd_mips_elf_find_nearest_line in bfd/elf32-mips.c,
which calls _bfd_ecoff_locate_line and lookup_line in
bfd/ecofflink.c.  Ignore the !stabs case in lookup_line.  The stabs
entries you find, marked with ECOFF_IS_STAB, are more or less normal.

Ian
From ac131313@cygnus.com Thu Nov 18 23:53:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: bsimon@ctam.com.au
Cc: gdb <gdb@sourceware.cygnus.com>
Subject: Re: GDB: libgdb
Date: Thu, 18 Nov 1999 23:53:00 -0000
Message-id: <383501C2.566B62A6@cygnus.com>
References: <38333038.E0FD1A6C@ctam.com.au>
X-SW-Source: 1999-q4/msg00287.html
Content-length: 585

Brendan Simon wrote:
> 
> Is libgdb available, useable or just a work in progress ?

It's definitly still work in progress.

> Any idea when GUI front ends can use libgdb as the api to gdb ?

The bigest barrer is me :-(  I need to stop fixing/rewriting remote.c
and go through and review / post the next set of proposed changes.  I
promised to do this a month ago.

I think the line ``real soon now like the cheque is in the mail''
probably applies.

On a brighter note, the remote.c work was to fix async problems and a
working async is a precursor to a working gdb library.

	Andrew
From mh15@st-andrews.ac.uk Fri Nov 19 03:34:00 1999
From: Mark Hindley <mh15@st-andrews.ac.uk>
To: gdb@sourceware.cygnus.com
Subject: Re: Debugging Windows Namespace extension dll 
Date: Fri, 19 Nov 1999 03:34:00 -0000
Message-id: <l03130300b45ae1b39084@[138.251.135.28]>
X-SW-Source: 1999-q4/msg00288.html
Content-length: 1952

Chris,

I have tracked down the Access Violation. It was in gdb. What it didn't
like was the fact that I had inherited 2 interfaces into the same class
implementation

class ShellFolder : public IShellFolder, IPersistFolder
{
}

This compiled fine, but caused gdb to choke.

I have now separated them out to different implementations, and gdb loads
the dll fine. It is abit inconvenient. I am not sure why gdb wont allow
multiple inheritances.

As far as actually debugging the dll, I still can't do it. Even putting
breakpoints on line numbers still fails.

This is what I am doing:

GNU gdb 4.18

Copyright 1998 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i386-mingw32".

(gdb)
exec-file /windows/explorer.exe


symbol-file macem.dll



set args /root, {53161ce0-56af-11d3-abb2-444553540001},



l CompObj.cpp:10

l CompObj.cpp:10

5       #include <windows.h>

6       #include <wTypes.h>

7       #include <objbase.h>

8       #include <initguid.h>

9       #include "MacEm.h"

10      #include "version.h"

11      #include "Classfac.h"

12

13      int cObject    = 0 ;

14      int cLockCount = 0 ;

(gdb) tb 13

tb 13

Breakpoint 1 at 0x661811a0: file CompObj.cpp, line 13.

(gdb) r

r

Starting program: /windows/explorer.exe /root,
{53161ce0-56af-11d3-abb2-444553540001},

bfb90000:C:/WINDOWS/SYSTEM/COMCTL32.DLL

bfb50000:C:/WINDOWS/SYSTEM/SHLWAPI.DLL

bff60000:C:/WINDOWS/SYSTEM/USER32.DLL

bff30000:C:/WINDOWS/SYSTEM/GDI32.DLL

bff70000:C:/WINDOWS/SYSTEM/KERNEL32.DLL

bfed0000:C:/WINDOWS/SYSTEM/ADVAPI32.DLL

Cannot insert breakpoint 1:

Cannot access memory at address 0x661811a0.

(gdb)



Am I doing something silly?

Thanks for your help

Re: dwarf2read problem

[Jim Blandy]

> Any chance of getting this fixed soon?  There's a simple testcase (source
> and Linux/x86/glibc 2.1 executable) at
> 
>   http://www.cygnus.com/~jason/ref.tar.gz

Sure.  I need to finish working on the alpha Linux thread support, but
once that's done...
From shebs@cygnus.com Fri Nov 19 13:57:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: bob.zulawnik@cportcorp.com
Cc: tpeng@metrowerks.com, gdb@sourceware.cygnus.com, binutils@sourceware.cygnus.com, bob.zulawnik@cportcorp.com
Subject: Re: Questions about GCC MIPS R5900's mdebug section
Date: Fri, 19 Nov 1999 13:57:00 -0000
Message-id: <199911192157.NAA18675@andros.cygnus.com>
References: <38357724.BF944599@cportcorp.com>
X-SW-Source: 1999-q4/msg00292.html
Content-length: 2099

   Date: Fri, 19 Nov 1999 11:13:25 -0500
   From: Bob Zulawnik <bob.zulawnik@cportcorp.com>

   Here is what appears to be a problem when running gdb
   on MIPS executables that use stabs for debug info (e.g.
   ECOFF/stabs or ELF/stabs), rather than 'original'
   ECOFF/mdebug format. If somebody could confirm/refute
   this, it would be very helpful indeed.

You wrote a nice description of a nasty process.  In case it's not
obvious to everybody, the reason to go to all this trouble is that the
basic MIPS calling convention doesn't include a frame pointer.  In his
very useful book See MIPS Run, Dominic Sweetman observes that
(probably referring to GDB :-) )

 "Some debuggers are quite heroic and will even interpret the first
 few instructions of a function to find out how large the stack frame
 is and to locate the stored return address." (p. 279)

       proc_desc =
	   heuristic_proc_desc (startaddr, pc, next_frame);

   which means that it starts reading function prologue
   (i.e. it reads instructions from inferior's memory) and it
   attempts to figure out information about it that way.
   While inelegant, it might work OK in native configurations
   (i.e. when gdb and inferior are running on the same host).
   However, the biggest problem will occur in remote configurations,
   where those memory reads have go through remote link. (A hack
   would make gdb read the executable file on the host side,
   rather than inferior's memory in a situation like that, just
   for speed's sake).

Beware of self-modifying and scribbled-upon code though - it would be
very confusing if the prologue analysis went perfectly, but variable
values and stepping behavior were nutso because the actual code on the
target was quite different.  Correctness is more important than speed.

   As mips-tdep.c contains MIPS target-dependent code, regardless
   of the particulars of debug info scheme in use, I would guess
   that the same problem should affect MIPS ELF/Dwarf files ? Or
   am I totally confused here ?

Yes, the issue is independent of specific debug format.

								Stan