* Re: PATCH: Step down from maintainerships
2004-10-17 19:59 ` Jim Blandy
@ 2004-10-19 19:43 ` Jim Blandy
2004-10-19 22:14 ` [RFA] Don't apply line-number tweaks for non-GCC compilers Mark Kettenis
2004-10-19 22:15 ` Mark Kettenis
2 siblings, 0 replies; 9+ messages in thread
From: Jim Blandy @ 2004-10-19 19:43 UTC (permalink / raw)
To: Elena Zannoni; +Cc: gdb-patches, Ton van Overbeek
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
^ permalink raw reply [flat|nested] 9+ messages in thread* [RFA] Don't apply line-number tweaks for non-GCC compilers
2004-10-17 19:59 ` Jim Blandy
2004-10-19 19:43 ` Jim Blandy
@ 2004-10-19 22:14 ` Mark Kettenis
2004-10-19 22:15 ` Mark Kettenis
2 siblings, 0 replies; 9+ messages in thread
From: Mark Kettenis @ 2004-10-19 22:14 UTC (permalink / raw)
To: ezannoni; +Cc: jimb, gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread* [RFA] Don't apply line-number tweaks for non-GCC compilers
2004-10-17 19:59 ` Jim Blandy
2004-10-19 19:43 ` Jim Blandy
2004-10-19 22:14 ` [RFA] Don't apply line-number tweaks for non-GCC compilers Mark Kettenis
@ 2004-10-19 22:15 ` Mark Kettenis
2004-11-09 13:16 ` Mark Kettenis
2 siblings, 1 reply; 9+ messages in thread
From: Mark Kettenis @ 2004-10-19 22:15 UTC (permalink / raw)
To: ezannoni; +Cc: jimb, gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFA] Don't apply line-number tweaks for non-GCC compilers
2004-10-19 22:15 ` Mark Kettenis
@ 2004-11-09 13:16 ` Mark Kettenis
2004-11-09 19:54 ` Jim Blandy
0 siblings, 1 reply; 9+ messages in thread
From: Mark Kettenis @ 2004-11-09 13:16 UTC (permalink / raw)
To: ezannoni; +Cc: jimb, gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFA] Don't apply line-number tweaks for non-GCC compilers
2004-11-09 13:16 ` Mark Kettenis
@ 2004-11-09 19:54 ` Jim Blandy
2004-11-18 22:38 ` Mark Kettenis
0 siblings, 1 reply; 9+ messages in thread
From: Jim Blandy @ 2004-11-09 19:54 UTC (permalink / raw)
To: Mark Kettenis; +Cc: ezannoni, gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [RFA] Don't apply line-number tweaks for non-GCC compilers
2004-11-09 19:54 ` Jim Blandy
@ 2004-11-18 22:38 ` Mark Kettenis
0 siblings, 0 replies; 9+ messages in thread
From: Mark Kettenis @ 2004-11-18 22:38 UTC (permalink / raw)
To: jimb; +Cc: ezannoni, gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread