PATCH: Step down from maintainerships

PATCH: Step down from maintainerships

[Jim Blandy]

After giving a lot of thought to how to get the most from limited
time, energy and ability, I've decided to step down from my GDB
maintainerships.  I've volunteered as symtab maintainer for five
years, and it's time to give other folks a turn.  I hope to continue
to contribute to GDB in other ways as I have since 1997.

There are a few outstanding patches that I had hoped to take care of
before stepping down, but then this last week some more came in, and I
realized I'd probably never get caught up.  If they remain unreviewed
I'll try to comment on them as I'm able; naturally, my reviews won't
be binding.


2004-10-10  Jim Blandy  <jimb@redhat.com>

	* MAINTAINERS (generic symtabs, dwarf readers, elf reader, stabs
	reader, tracing bytecode stuff): Remove self.

Index: gdb/MAINTAINERS
===================================================================
RCS file: /cvs/src/src/gdb/MAINTAINERS,v
retrieving revision 1.290
diff -c -p -r1.290 MAINTAINERS
*** gdb/MAINTAINERS	8 Oct 2004 01:35:48 -0000	1.290
--- gdb/MAINTAINERS	10 Oct 2004 21:55:11 -0000
*************** gdb/MAINTAINERS		Elena Zannoni           ezan
*** 217,238 ****
                          For the part of top.c related to the event loop,
                          send questions to ezannoni@redhat.com
  
! generic symtabs		Jim Blandy		jimb@redhat.com
! 			Elena Zannoni		ezannoni@redhat.com
!   dwarf readers		Jim Blandy		jimb@redhat.com
! 			Elena Zannoni		ezannoni@redhat.com
!   elf reader		Jim Blandy		jimb@redhat.com
! 			Elena Zannoni		ezannoni@redhat.com
!   stabs reader		Jim Blandy		jimb@redhat.com
! 			Elena Zannoni		ezannoni@redhat.com
    coff reader		Philippe De Muyter	phdm@macqel.be
    xcoff reader		Any maintainer can modify this; please send tricky
  			ones to Kevin Buettner <kevinb@redhat.com>
    HP/UX readers		Any [past] maintainer can modify this.
  			Please send tricky ones to the symtabs maintainers.
  
! tracing bytecode stuff  Jim Blandy              jimb@redhat.com
!                         (Global Maintainers)
  tracing			Michael Snyder		msnyder@redhat.com
  threads			Michael Snyder		msnyder@redhat.com
  			Mark Kettenis		kettenis@gnu.org
--- 217,233 ----
                          For the part of top.c related to the event loop,
                          send questions to ezannoni@redhat.com
  
! generic symtabs		Elena Zannoni		ezannoni@redhat.com
!   dwarf readers		Elena Zannoni		ezannoni@redhat.com
!   elf reader		Elena Zannoni		ezannoni@redhat.com
!   stabs reader		Elena Zannoni		ezannoni@redhat.com
    coff reader		Philippe De Muyter	phdm@macqel.be
    xcoff reader		Any maintainer can modify this; please send tricky
  			ones to Kevin Buettner <kevinb@redhat.com>
    HP/UX readers		Any [past] maintainer can modify this.
  			Please send tricky ones to the symtabs maintainers.
  
! tracing bytecode stuff  (Global Maintainers)
  tracing			Michael Snyder		msnyder@redhat.com
  threads			Michael Snyder		msnyder@redhat.com
  			Mark Kettenis		kettenis@gnu.org

Re: PATCH: Step down from maintainerships

[Elena Zannoni]

Jim Blandy writes:
 > 
 > There are a few outstanding patches that I had hoped to take care of
 > before stepping down, but then this last week some more came in, and I
 > realized I'd probably never get caught up.  

Jim, send a list of pointers (with URLs) to the patches and I'll take
care of them.

Re: PATCH: Step down from maintainerships

[Jim Blandy]

Elena Zannoni <ezannoni@redhat.com> writes:
> Jim Blandy writes:
>  > 
>  > There are a few outstanding patches that I had hoped to take care of
>  > before stepping down, but then this last week some more came in, and I
>  > realized I'd probably never get caught up.  
> 
> Jim, send a list of pointers (with URLs) to the patches and I'll take
> care of them.

Okay, great.  Here are the ones that I know about:

- Demangling language needs to be stored in demangled name cache,
  along with demangled name:

    http://sources.redhat.com/ml/gdb-patches/2004-08/msg00479.html

  The patch proposed there would undo prior optimizations, which I
  explain here:

    http://sources.redhat.com/ml/gdb-patches/2004-09/msg00263.html

  (That message is not part of the same thread, since it's in a
  different month, so don't miss it.)

- Intel Fortran 90 emits debugging information for nested subroutines
  that produces a malformed block tree:
    http://sources.redhat.com/ml/gdb-patches/2004-08/msg00183.html

  The thread resumes here:
    http://sources.redhat.com/ml/gdb-patches/2004-09/msg00239.html

- GDB's stabs reader tweaks line number information, in a way that's
  not appropriate for non-GCC stabs.  Mark Kettenis posted a patch,
  and I suggested a revision; I think that's where it stands.

    http://sources.redhat.com/ml/gdb-patches/2004-09/msg00234.html

- Corinna Vinschen proposed a new gdbarch method to let arch-specific
  code interpret Dwarf 2 DW_AT_calling_convention attributes:

    http://sources.redhat.com/ml/gdb-patches/2004-10/msg00146.html

Re: PATCH: Step down from maintainerships

[Jim Blandy]

Jim Blandy <jimb@redhat.com> writes:
> - Demangling language needs to be stored in demangled name cache,
>   along with demangled name:
> 
>     http://sources.redhat.com/ml/gdb-patches/2004-08/msg00479.html
> 
>   The patch proposed there would undo prior optimizations, which I
>   explain here:
> 
>     http://sources.redhat.com/ml/gdb-patches/2004-09/msg00263.html
> 
>   (That message is not part of the same thread, since it's in a
>   different month, so don't miss it.)

For what it's worth, I have a tentative patch for this.  It's not
tested, but it could be a starting point.  (Ton van Overbeek
originally reported the problem, and has offered to test patches.)

2004-10-19  Jim Blandy  <jimb@redhat.com>

	* symtab.c (symbol_set_names): Store the demangling language, as
	well as the demangled name, in the demangling cache.  Use it to
	set the language on symbols whose names we find in the cache.
	* objfiles.h (struct objfile): Doc fix.

Index: gdb/objfiles.h
===================================================================
RCS file: /cvs/src/src/gdb/objfiles.h,v
retrieving revision 1.39
diff -c -p -r1.39 objfiles.h
*** gdb/objfiles.h	2 Sep 2004 03:05:46 -0000	1.39
--- gdb/objfiles.h	19 Oct 2004 19:23:20 -0000
*************** struct objfile
*** 267,275 ****
  
      /* Hash table for mapping symbol names to demangled names.  Each
         entry in the hash table is actually two consecutive strings,
!        both null-terminated; the first one is a mangled or linkage
!        name, and the second is the demangled name or just a zero byte
!        if the name doesn't demangle.  */
      struct htab *demangled_names_hash;
  
      /* Vectors of all partial symbols read in from file.  The actual data
--- 267,280 ----
  
      /* Hash table for mapping symbol names to demangled names.  Each
         entry in the hash table is actually two consecutive strings,
!        both null-terminated, possibly followed by a byte:
!        - the first string is a mangled or linkage name, 
!        - the second string is the demangled name, or just a zero byte
!          if the name doesn't demangle, and
!        - if the demangled name is non-empty, the byte after the second
!          null character is the 'enum language' value for the
!          demangling regimen we used.  If the demangled name is empty,
!          the byte is absent.  */
      struct htab *demangled_names_hash;
  
      /* Vectors of all partial symbols read in from file.  The actual data
Index: gdb/symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.140
diff -c -p -r1.140 symtab.c
*** gdb/symtab.c	2 Oct 2004 09:55:15 -0000	1.140
--- gdb/symtab.c	19 Oct 2004 19:23:21 -0000
*************** symbol_set_names (struct general_symbol_
*** 576,598 ****
  	 Otherwise, just place a second zero byte after the end of the mangled
  	 name.  */
        *slot = obstack_alloc (&objfile->objfile_obstack,
! 			     lookup_len + demangled_len + 2);
        memcpy (*slot, lookup_name, lookup_len + 1);
        if (demangled_name != NULL)
  	{
  	  memcpy (*slot + lookup_len + 1, demangled_name, demangled_len + 1);
  	  xfree (demangled_name);
  	}
        else
  	(*slot)[lookup_len + 1] = '\0';
      }
  
    gsymbol->name = *slot + lookup_len - len;
!   if ((*slot)[lookup_len + 1] != '\0')
!     gsymbol->language_specific.cplus_specific.demangled_name
!       = &(*slot)[lookup_len + 1];
!   else
!     gsymbol->language_specific.cplus_specific.demangled_name = NULL;
  }
  
  /* Initialize the demangled name of GSYMBOL if possible.  Any required space
--- 576,624 ----
  	 Otherwise, just place a second zero byte after the end of the mangled
  	 name.  */
        *slot = obstack_alloc (&objfile->objfile_obstack,
! 			     lookup_len + 1 + demangled_len + 1 + 1);
        memcpy (*slot, lookup_name, lookup_len + 1);
        if (demangled_name != NULL)
  	{
  	  memcpy (*slot + lookup_len + 1, demangled_name, demangled_len + 1);
  	  xfree (demangled_name);
+           /* Record the language we used to demangle the name, too.  */
+           (*slot)[lookup_len + 1 + demangled_len + 1] = gsymbol->language;
  	}
        else
  	(*slot)[lookup_len + 1] = '\0';
      }
+   else
+     {
+       /* This is what symbol_find_demangled_name does when we don't
+          find a hash table entry, so we should do it when we do find
+          one as well.  */
+       if (gsymbol->language == language_unknown)
+         gsymbol->language = language_auto;
+     }
  
+   /* At this point we've definitely got a hash table entry, whether
+      prexisting or just created.  Make gsymbol share its name with
+      the hash table entry.  */
    gsymbol->name = *slot + lookup_len - len;
! 
!   /* Share the demangled name as well, if there is one.  */
!   {
!     char *demangled_name = *slot + lookup_len + 1;
! 
!     if (demangled_name != '\0')
!       {
!         size_t demangled_len = strlen (demangled_name);
! 
!         gsymbol->language_specific.cplus_specific.demangled_name
!           = demangled_name;
! 
!         /* Set gsymbol's language from the byte after the demangled name.  */
!         gsymbol->language = (enum language) demangled_name[demangled_len + 1];
!       }
!     else
!       gsymbol->language_specific.cplus_specific.demangled_name = NULL;
!   }
  }
  
  /* Initialize the demangled name of GSYMBOL if possible.  Any required space

[RFA] Don't apply line-number tweaks for non-GCC compilers

[Mark Kettenis]

   From: Jim Blandy <jimb@redhat.com>
   Date: 17 Oct 2004 14:57:22 -0500

   Elena Zannoni <ezannoni@redhat.com> writes:
   > 
   > Jim, send a list of pointers (with URLs) to the patches and I'll take
   > care of them.

   Okay, great.  Here are the ones that I know about:

   - GDB's stabs reader tweaks line number information, in a way that's
     not appropriate for non-GCC stabs.  Mark Kettenis posted a patch,
     and I suggested a revision; I think that's where it stands.

       http://sources.redhat.com/ml/gdb-patches/2004-09/msg00234.html

I had a follow-up patch, but I lost it when I accidentally did an rm
-rf of my GDB working directory.  Anyway, here's a new one that
implements Jim's suggestion.  OK?

I'd really like to check this in on the new release branch too, since
I promised to fix this a long time ago.

Mark


Index: dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.74
diff -u -p -r1.74 dbxread.c
--- dbxread.c 11 Sep 2004 10:24:46 -0000 1.74
+++ dbxread.c 19 Oct 2004 20:32:34 -0000
@@ -2927,11 +2927,26 @@ process_one_symbol (int type, int desc, 
       /* Relocate for dynamic loading and for ELF acc fn-relative syms.  */
       valu += function_start_offset;
 
-      /* If this is the first SLINE note in the function, record it at
-	 the start of the function instead of at the listed location.  */
+      /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the
+	 middle of the prologue instead of right at the start of the
+	 function.  To deal with this we record the address for the
+	 first N_SLINE stab to be the start of the function instead of
+	 the listed location.  We really shouldn't to this.  When
+	 compiling with optimization, this first N_SLINE stab might be
+	 optimized away.  Other (non-GCC) compilers don't emit this
+	 stab at all.  There is no real harm in having an extra
+	 numbered line, although it can be a bit annoying for the
+	 user.  However, it totally screws up our testsuite.
+
+	 So for now, keep adjusting the address of the first N_SLINE
+	 stab, but only for code compiled with GCC.  */
+
       if (within_function && sline_found_in_function == 0)
 	{
-	  record_line (current_subfile, desc, last_function_start);
+	  if (processing_gcc_compilation == 2)
+	    record_line (current_subfile, desc, last_function_start);
+	  else
+	    record_line (current_subfile, desc, valu);
 	  sline_found_in_function = 1;
 	}
       else

[RFA] Don't apply line-number tweaks for non-GCC compilers

[Mark Kettenis]

   From: Jim Blandy <jimb@redhat.com>
   Date: 17 Oct 2004 14:57:22 -0500

[Oops.  Now with ChangeLog.]

   Elena Zannoni <ezannoni@redhat.com> writes:
   > 
   > Jim, send a list of pointers (with URLs) to the patches and I'll take
   > care of them.

   Okay, great.  Here are the ones that I know about:

   - GDB's stabs reader tweaks line number information, in a way that's
     not appropriate for non-GCC stabs.  Mark Kettenis posted a patch,
     and I suggested a revision; I think that's where it stands.

       http://sources.redhat.com/ml/gdb-patches/2004-09/msg00234.html

I had a follow-up patch, but I lost it when I accidentally did an rm
-rf of my GDB working directory.  Anyway, here's a new one that
implements Jim's suggestion.  OK?

I'd really like to check this in on the new release branch too, since
I promised to fix this a long time ago.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>
 
	* dbxread.c (process_one_symbol): Do not adjust address of first
	N_SLINE stab for a function for code generated by non-GCC
	compilers.

 
Index: dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.74
diff -u -p -r1.74 dbxread.c
--- dbxread.c 11 Sep 2004 10:24:46 -0000 1.74
+++ dbxread.c 19 Oct 2004 20:45:53 -0000
@@ -2927,11 +2927,26 @@ process_one_symbol (int type, int desc, 
       /* Relocate for dynamic loading and for ELF acc fn-relative syms.  */
       valu += function_start_offset;
 
-      /* If this is the first SLINE note in the function, record it at
-	 the start of the function instead of at the listed location.  */
+      /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the
+	 middle of the prologue instead of right at the start of the
+	 function.  To deal with this we record the address for the
+	 first N_SLINE stab to be the start of the function instead of
+	 the listed location.  We really shouldn't to this.  When
+	 compiling with optimization, this first N_SLINE stab might be
+	 optimized away.  Other (non-GCC) compilers don't emit this
+	 stab at all.  There is no real harm in having an extra
+	 numbered line, although it can be a bit annoying for the
+	 user.  However, it totally screws up our testsuite.
+
+	 So for now, keep adjusting the address of the first N_SLINE
+	 stab, but only for code compiled with GCC.  */
+
       if (within_function && sline_found_in_function == 0)
 	{
-	  record_line (current_subfile, desc, last_function_start);
+	  if (processing_gcc_compilation == 2)
+	    record_line (current_subfile, desc, last_function_start);
+	  else
+	    record_line (current_subfile, desc, valu);
 	  sline_found_in_function = 1;
 	}
       else

Re: [RFA] Don't apply line-number tweaks for non-GCC compilers

[Mark Kettenis]

   Date: Wed, 20 Oct 2004 00:15:02 +0200 (CEST)
   From: Mark Kettenis <mark.kettenis@xs4all.nl>

Ping!

      - GDB's stabs reader tweaks line number information, in a way that's
	not appropriate for non-GCC stabs.  Mark Kettenis posted a patch,
	and I suggested a revision; I think that's where it stands.

	  http://sources.redhat.com/ml/gdb-patches/2004-09/msg00234.html

   I had a follow-up patch, but I lost it when I accidentally did an rm
   -rf of my GDB working directory.  Anyway, here's a new one that
   implements Jim's suggestion.  OK?

   I'd really like to check this in on the new release branch too, since
   I promised to fix this a long time ago.

   Mark


   Index: ChangeLog
   from  Mark Kettenis  <kettenis@gnu.org>

	   * dbxread.c (process_one_symbol): Do not adjust address of first
	   N_SLINE stab for a function for code generated by non-GCC
	   compilers.


   Index: dbxread.c
   ===================================================================
   RCS file: /cvs/src/src/gdb/dbxread.c,v
   retrieving revision 1.74
   diff -u -p -r1.74 dbxread.c
   --- dbxread.c 11 Sep 2004 10:24:46 -0000 1.74
   +++ dbxread.c 19 Oct 2004 20:45:53 -0000
   @@ -2927,11 +2927,26 @@ process_one_symbol (int type, int desc, 
	  /* Relocate for dynamic loading and for ELF acc fn-relative syms.  */
	  valu += function_start_offset;

   -      /* If this is the first SLINE note in the function, record it at
   -	 the start of the function instead of at the listed location.  */
   +      /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the
   +	 middle of the prologue instead of right at the start of the
   +	 function.  To deal with this we record the address for the
   +	 first N_SLINE stab to be the start of the function instead of
   +	 the listed location.  We really shouldn't to this.  When
   +	 compiling with optimization, this first N_SLINE stab might be
   +	 optimized away.  Other (non-GCC) compilers don't emit this
   +	 stab at all.  There is no real harm in having an extra
   +	 numbered line, although it can be a bit annoying for the
   +	 user.  However, it totally screws up our testsuite.
   +
   +	 So for now, keep adjusting the address of the first N_SLINE
   +	 stab, but only for code compiled with GCC.  */
   +
	  if (within_function && sline_found_in_function == 0)
	   {
   -	  record_line (current_subfile, desc, last_function_start);
   +	  if (processing_gcc_compilation == 2)
   +	    record_line (current_subfile, desc, last_function_start);
   +	  else
   +	    record_line (current_subfile, desc, valu);
	     sline_found_in_function = 1;
	   }
	  else

Re: [RFA] Don't apply line-number tweaks for non-GCC compilers

[Jim Blandy]

For what it's worth, this change implements the suggestion I made.

Mark Kettenis <kettenis@gnu.org> writes:

>    Date: Wed, 20 Oct 2004 00:15:02 +0200 (CEST)
>    From: Mark Kettenis <mark.kettenis@xs4all.nl>
> 
> Ping!
> 
>       - GDB's stabs reader tweaks line number information, in a way that's
> 	not appropriate for non-GCC stabs.  Mark Kettenis posted a patch,
> 	and I suggested a revision; I think that's where it stands.
> 
> 	  http://sources.redhat.com/ml/gdb-patches/2004-09/msg00234.html
> 
>    I had a follow-up patch, but I lost it when I accidentally did an rm
>    -rf of my GDB working directory.  Anyway, here's a new one that
>    implements Jim's suggestion.  OK?
> 
>    I'd really like to check this in on the new release branch too, since
>    I promised to fix this a long time ago.
> 
>    Mark
> 
> 
>    Index: ChangeLog
>    from  Mark Kettenis  <kettenis@gnu.org>
> 
> 	   * dbxread.c (process_one_symbol): Do not adjust address of first
> 	   N_SLINE stab for a function for code generated by non-GCC
> 	   compilers.
> 
> 
>    Index: dbxread.c
>    ===================================================================
>    RCS file: /cvs/src/src/gdb/dbxread.c,v
>    retrieving revision 1.74
>    diff -u -p -r1.74 dbxread.c
>    --- dbxread.c 11 Sep 2004 10:24:46 -0000 1.74
>    +++ dbxread.c 19 Oct 2004 20:45:53 -0000
>    @@ -2927,11 +2927,26 @@ process_one_symbol (int type, int desc, 
> 	  /* Relocate for dynamic loading and for ELF acc fn-relative syms.  */
> 	  valu += function_start_offset;
> 
>    -      /* If this is the first SLINE note in the function, record it at
>    -	 the start of the function instead of at the listed location.  */
>    +      /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the
>    +	 middle of the prologue instead of right at the start of the
>    +	 function.  To deal with this we record the address for the
>    +	 first N_SLINE stab to be the start of the function instead of
>    +	 the listed location.  We really shouldn't to this.  When
>    +	 compiling with optimization, this first N_SLINE stab might be
>    +	 optimized away.  Other (non-GCC) compilers don't emit this
>    +	 stab at all.  There is no real harm in having an extra
>    +	 numbered line, although it can be a bit annoying for the
>    +	 user.  However, it totally screws up our testsuite.
>    +
>    +	 So for now, keep adjusting the address of the first N_SLINE
>    +	 stab, but only for code compiled with GCC.  */
>    +
> 	  if (within_function && sline_found_in_function == 0)
> 	   {
>    -	  record_line (current_subfile, desc, last_function_start);
>    +	  if (processing_gcc_compilation == 2)
>    +	    record_line (current_subfile, desc, last_function_start);
>    +	  else
>    +	    record_line (current_subfile, desc, valu);
> 	     sline_found_in_function = 1;
> 	   }
> 	  else

Re: [RFA] Don't apply line-number tweaks for non-GCC compilers

[Mark Kettenis]

   From: Jim Blandy <jimb@redhat.com>
   Date: 09 Nov 2004 14:53:03 -0500

   For what it's worth, this change implements the suggestion I made.

I went ahead and checked this in.

Mark

   >    Index: ChangeLog
   >    from  Mark Kettenis  <kettenis@gnu.org>
   > 
   > 	   * dbxread.c (process_one_symbol): Do not adjust address of first
   > 	   N_SLINE stab for a function for code generated by non-GCC
   > 	   compilers.
   > 
   > 
   >    Index: dbxread.c
   >    ===================================================================
   >    RCS file: /cvs/src/src/gdb/dbxread.c,v
   >    retrieving revision 1.74
   >    diff -u -p -r1.74 dbxread.c
   >    --- dbxread.c 11 Sep 2004 10:24:46 -0000 1.74
   >    +++ dbxread.c 19 Oct 2004 20:45:53 -0000
   >    @@ -2927,11 +2927,26 @@ process_one_symbol (int type, int desc, 
   > 	  /* Relocate for dynamic loading and for ELF acc fn-relative syms.  */
   > 	  valu += function_start_offset;
   > 
   >    -      /* If this is the first SLINE note in the function, record it at
   >    -	 the start of the function instead of at the listed location.  */
   >    +      /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the
   >    +	 middle of the prologue instead of right at the start of the
   >    +	 function.  To deal with this we record the address for the
   >    +	 first N_SLINE stab to be the start of the function instead of
   >    +	 the listed location.  We really shouldn't to this.  When
   >    +	 compiling with optimization, this first N_SLINE stab might be
   >    +	 optimized away.  Other (non-GCC) compilers don't emit this
   >    +	 stab at all.  There is no real harm in having an extra
   >    +	 numbered line, although it can be a bit annoying for the
   >    +	 user.  However, it totally screws up our testsuite.
   >    +
   >    +	 So for now, keep adjusting the address of the first N_SLINE
   >    +	 stab, but only for code compiled with GCC.  */
   >    +
   > 	  if (within_function && sline_found_in_function == 0)
   > 	   {
   >    -	  record_line (current_subfile, desc, last_function_start);
   >    +	  if (processing_gcc_compilation == 2)
   >    +	    record_line (current_subfile, desc, last_function_start);
   >    +	  else
   >    +	    record_line (current_subfile, desc, valu);
   > 	     sline_found_in_function = 1;
   > 	   }
   > 	  else