headers
Dave Korn | 1 Sep 2005 12:29
Favicon

[PATCH PING] RE: [PATCH] Your patch from 20050512 b0rked on cygwin!

----Original Message----
>From: Dave Korn
>Sent: 17 August 2005 17:39

  Ping CGF?  HEAD doesn't build on cygwin.

http://sources.redhat.com/ml/gdb-patches/2005-08/msg00198.html

Also, the change log entry got wrapped.  Reformatted.

2005-08-17  Dave Korn  <dave.korn <at> artimi.com>

	* win32-nat.c (solib_address): Rename from this ...
	(win32_nat_solib_address): ... to this, to avoid clash with solib.c
	(child_solib_loaded_library_pathname, child_clear_solibs)
	(dll_symbol_command): Likewise rename to ...
	(win32_nat_child_solib_loaded_library_pathname)
	(win32_nat_child_clear_solibs, win32_nat_dll_symbol_command): ...
	these, and all call sites adjusted.

	* config/i386/tm-cygwin.h (SOLIB_ADD, SOLIB_LOADED_LIBRARY_PATHNAME)
	(CLEAR_SOLIB, ADD_SHARED_SYMBOL_FILES, PC_SOLIB):  Add 'win32_nat_'
	prefix to all symbols to match renamed functions in win32-nat.c.

    cheers,
      DaveK
--

-- 
Can't think of a witty .sigline today....
(Continue reading)

Permalink | Reply | 3 comments |
headers
Frederic RISS | 1 Sep 2005 13:28

MI mixed disassembly address range issue

Hello,

when using the -data-disassemble MI command with the -s and -e options
to specify the address range to disassemble, it's quit easy to break the
following assumption in disasm.c :

  /* Assume symtab is valid for whole PC range */
  symtab = find_pc_symtab (low);

If the low and high address' aren't recorded in the same symtab, we hit
this code in do_mixed_source_and_assembly :

  /* If we're on the last line, and it's part of the function,
     then we need to get the end pc in a special way.  */

  if (i == nlines - 1 && le[i].pc < high)
    {
      mle[newlines].line = le[i].line;
      mle[newlines].start_pc = le[i].pc;
      sal = find_pc_line (le[i].pc, 0);
      mle[newlines].end_pc = sal.end;
      newlines++;
    }

I tested this with the Dwarf2 debug format which introduces
'end-of-function' markers (ie lineentries with 0 as line number). When
reaching the end of the table, the above code introduces an entry with 0
line number in the 'lines to be dumped' array. 
The result is like that :
(Continue reading)

Permalink | Reply | 0 comments |
headers
Konstantin Karganov | 1 Sep 2005 19:10
Picon

Auto variables display

Hello, All.

In MS Visual Studio debugger there is a very convenient feature - "Auto" 
watch window tab, which displays the variables, referenced at the current 
program statement. I.e. when you step across "i=j;" it displays i and j, 
when you step across "x=f(a+b,*c)" displays a,b and c, etc.
This allows to see automatically just the values that affect current step 
execution and see the error when and where it happens.

The question is: does GDB support something like this and also are
there the debug info formats that provide the mapping of the source lines 
(or code addresses) to the set of variables, references at the point?

TIA,
Konstantin.
Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Sep 2005 19:58

Re: Auto variables display

On Thu, Sep 01, 2005 at 09:10:48PM +0400, Konstantin Karganov wrote:
> Hello, All.
> 
> In MS Visual Studio debugger there is a very convenient feature - "Auto" 
> watch window tab, which displays the variables, referenced at the current 
> program statement. I.e. when you step across "i=j;" it displays i and j, 
> when you step across "x=f(a+b,*c)" displays a,b and c, etc.
> This allows to see automatically just the values that affect current step 
> execution and see the error when and where it happens.
> 
> The question is: does GDB support something like this and also are
> there the debug info formats that provide the mapping of the source lines 
> (or code addresses) to the set of variables, references at the point?

As far as I know, no and no.

--

-- 
Daniel Jacobowitz
CodeSourcery, LLC
Permalink | Reply | 0 comments |
headers
Manoj Iyer | 1 Sep 2005 21:32
Picon
Favicon

infinite loop from backtrace in gdb (Powerpc64)


I am seeing an infinite loop from backtrace in gdb.6.3 on Powerpc64, looks
much like the problem Michael tried to fix for MIPS. In my case a library
that the app links to calls abort(), the remainder of backtrace from the
library seems cause gdb to go into an infinite loop.

Any clues?

 On Tue, 20 Apr 2004, Daniel Jacobowitz wrote:

> On Wed, Apr 21, 2004 at 12:20:53AM +0000, Michael Snyder wrote:
> > Hi Andrew,
> >
> > This change will prevent the caller(s) of mips_mdebug_frame_id from
> > infinite-looping when we get badly lost on the stack frame.
> >
>
> > 2004-04-21  Michael Snyder  <msnyder <at> redhat.com>
> >
> > 	* mips-tdep.c (mips_mdebug_frame_cache): Call error to prevent
> > 	infinite looping by caller.
> > 	(heuristic_proc_start): Warning() already prefixes "Warning: ".
>
> Since I have some patches to make this "I'm not sure how" case into a
> working part of the unwinder, I don't much like this.  They got hung up
> on the question of how to trust proc_desc's when we might be in the
> prologue.
>
> One time where this case occurs is in backtracing from a NULL pointer
> dereference, which happens in the GDB testsuite now.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Craig Jeffree | 2 Sep 2005 01:55

Re: <incomplete type>

On Mon, 2005-08-29 at 11:31 -0700, Jim Blandy wrote:
> The leftmost number in <angle brackets> is the nesting level of that
> die; so if the entry for the die after the first one you listed starts
> with <2>, then it's a child of the <1> die.  There should be
> DW_TAG_member(?) dies.

Ah, now I can see some sense in these dies.  Looking in the actual
executable I can see this...

 <1><c74a688>: Abbrev Number: 114 (DW_TAG_structure_type)
     DW_AT_sibling     : <c74aadf>
     DW_AT_name        : (indirect string, offset: 0x4ff824): Waypoint
     DW_AT_byte_size   : 92
     DW_AT_decl_file   : 60
     DW_AT_decl_line   : 28
     DW_AT_containing_type: <c74b7e1>
 <2><c74a698>: Abbrev Number: 54 (DW_TAG_inheritance)
     DW_AT_type        : <c74abb4>
     DW_AT_data_member_location: 2 byte block: 23 0
(DW_OP_plus_uconst: 0)
     DW_AT_accessibility: 1     (public)
 <2><c74a6a1>: Abbrev Number: 56 (DW_TAG_variable)
     DW_AT_name        : (indirect string, offset: 0x837e8): typeName_
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 17
     DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8e402b):
_ZN3Soi8Waypoint9typeName_E
     DW_AT_type        : <c74b7af>
     DW_AT_external    : 1
     DW_AT_declaration : 1
(Continue reading)

Permalink | Reply | 10 comments |
headers
Jim Blandy | 2 Sep 2005 02:20
Picon
Favicon

Re: <incomplete type>


Craig Jeffree <craig.jeffree <at> preston.net> writes:
> On Mon, 2005-08-29 at 11:31 -0700, Jim Blandy wrote:
>> The leftmost number in <angle brackets> is the nesting level of that
>> die; so if the entry for the die after the first one you listed starts
>> with <2>, then it's a child of the <1> die.  There should be
>> DW_TAG_member(?) dies.
>
> Ah, now I can see some sense in these dies.  Looking in the actual
> executable I can see this...
>
>  <1><c74a688>: Abbrev Number: 114 (DW_TAG_structure_type)
>      DW_AT_sibling     : <c74aadf>
>      DW_AT_name        : (indirect string, offset: 0x4ff824): Waypoint
>      DW_AT_byte_size   : 92
>      DW_AT_decl_file   : 60
>      DW_AT_decl_line   : 28
>      DW_AT_containing_type: <c74b7e1>
>  <2><c74a698>: Abbrev Number: 54 (DW_TAG_inheritance)
>      DW_AT_type        : <c74abb4>
>      DW_AT_data_member_location: 2 byte block: 23 0
> (DW_OP_plus_uconst: 0)
>      DW_AT_accessibility: 1     (public)
>  <2><c74a6a1>: Abbrev Number: 56 (DW_TAG_variable)
>      DW_AT_name        : (indirect string, offset: 0x837e8): typeName_
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 17
>      DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8e402b):
> _ZN3Soi8Waypoint9typeName_E
>      DW_AT_type        : <c74b7af>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Craig Jeffree | 2 Sep 2005 03:49

Re: <incomplete type>

On Thu, 2005-09-01 at 17:20 -0700, Jim Blandy wrote:
> If you run GDB on the executable alone, without starting it, what does
> 'ptype struct Soi::Waypoint' say?  (Running the program will load
> shared libraries and possibly confuse the issue, but GDB should be
> able to understand the info in the executable without running
> anything.)

  (gdb) ptype struct Soi::Waypoint
  No struct type named Soi.
[That's right, Soi's a namespace, but why doesn't it recongnise
Soi::Waypoint as a struct?]

  (gdb) ptype Soi::Waypoint
  type = namespace Soi::Waypoint
[Waypoint isn't a namespace though, its a class!]

  (gdb) ptype Soi
  type = namespace Soi

  (gdb) ptype struct Waypoint
  Internal: global symbol `Waypoint' found in SoiWaypoint.C psymtab but
not in symtab.
  Waypoint may be an inlined function, or may be a template function
  (if a template, try specifying an instantiation: Waypoint<type>).
[Waypoint isn't a template, it is a fairly normal class]

  (gdb) ptype Soi::Waypoint::wpll_
  type = class AdmLatLong { [long class decl] } ( Soi::Waypoint::&)

  (gdb) ptype Soi::Waypoint::wpname_
(Continue reading)

Permalink | Reply | 7 comments |
headers
Craig Jeffree | 1 Sep 2005 11:09

Re: <incomplete type>

On Mon, 2005-08-29 at 11:31 -0700, Jim Blandy wrote:
> The leftmost number in <angle brackets> is the nesting level of that
> die; so if the entry for the die after the first one you listed starts
> with <2>, then it's a child of the <1> die.  There should be
> DW_TAG_member(?) dies.

Ah, now I can see some sense in these dies.  Looking in the actual
executable I can see this...

 <1><c74a688>: Abbrev Number: 114 (DW_TAG_structure_type)
     DW_AT_sibling     : <c74aadf>
     DW_AT_name        : (indirect string, offset: 0x4ff824): Waypoint
     DW_AT_byte_size   : 92
     DW_AT_decl_file   : 60
     DW_AT_decl_line   : 28
     DW_AT_containing_type: <c74b7e1>
 <2><c74a698>: Abbrev Number: 54 (DW_TAG_inheritance)
     DW_AT_type        : <c74abb4>
     DW_AT_data_member_location: 2 byte block: 23 0
(DW_OP_plus_uconst: 0)
     DW_AT_accessibility: 1     (public)
 <2><c74a6a1>: Abbrev Number: 56 (DW_TAG_variable)
     DW_AT_name        : (indirect string, offset: 0x837e8): typeName_
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 17
     DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8e402b):
_ZN3Soi8Waypoint9typeName_E
     DW_AT_type        : <c74b7af>
     DW_AT_external    : 1
     DW_AT_declaration : 1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vladimir Prus | 2 Sep 2005 08:50
Picon
Favicon

Re: Auto variables display

Hi Konstantin,

> Hello, All.
> 
> In MS Visual Studio debugger there is a very convenient feature - "Auto"
> watch window tab, which displays the variables, referenced at the current
> program statement. I.e. when you step across "i=j;" it displays i and j,
> when you step across "x=f(a+b,*c)" displays a,b and c, etc.
> This allows to see automatically just the values that affect current step
> execution and see the error when and where it happens.
> 
> The question is: does GDB support something like this and also are
> there the debug info formats that provide the mapping of the source lines
> (or code addresses) to the set of variables, references at the point?

I suspect that MS debugger does not have such information either, and merely
looks at all identifiers at the current line and tries to fetch them. That
should be possible to implement using gdb, as well.

- Volodya
Permalink | Reply | 0 comments |

Gmane