From: Joel Brobecker <brobecker@ACT-Europe.FR>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Uninitialized section index internal error on Tru64 5.1
Date: Tue, 16 Apr 2002 10:40:00 -0000 [thread overview]
Message-ID: <20020416193952.A1404@act-europe.fr> (raw)
In-Reply-To: <15546.1263.304306.933281@localhost.redhat.com>; from ezannoni@redhat.com on Sun, Apr 14, 2002 at 06:38:39PM -0400
[-- Attachment #1: Type: text/plain, Size: 964 bytes --]
Thank you Elena for reviewing my changes. May I suggest the following
patch for inclusion, then?
2002-04-16 J. Brobecker <brobecker@gnat.com>
* symfile.h (get_section_index): Define.
* symfile.c (get_section_index): New function.
* mdebugread.c (SC_IS_SBSS): New macro.
(SC_IS_BSS): Return true for the scBss storage class only, as
the scSBss storage class refers to the .sbss section.
(parse_partial_symbols): Discard the symbols which associated
section does not exist.
Make sure to use the .sbss section index for symbols which
storage class is scBss, rather than using the .bss section index.
One additional note: I split the SC_IS_BSS macro into 2 macros, one for
scBss and one for scSBss. I wonder if the same should not be done for
the SC_IS_TEXT and SC_IS_DATA macros as well. So far, I haven't found a
case where this causes a problem, so left them unchanged for now.
--
Joel
[-- Attachment #2: sect_index_uninitialized.diff --]
[-- Type: text/plain, Size: 5618 bytes --]
Index: symfile.h
===================================================================
RCS file: /cvs/src/src/gdb/symfile.h,v
retrieving revision 1.12
diff -c -3 -p -r1.12 symfile.h
*** symfile.h 1 Feb 2002 01:14:20 -0000 1.12
--- symfile.h 16 Apr 2002 13:18:36 -0000
*************** extern void find_lowest_section (bfd *,
*** 252,257 ****
--- 252,259 ----
extern bfd *symfile_bfd_open (char *);
+ extern int get_section_index (struct objfile *, char *);
+
/* Utility functions for overlay sections: */
extern enum overlay_debugging_state {
ovly_off,
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.58
diff -c -3 -p -r1.58 symfile.c
*** symfile.c 29 Mar 2002 01:09:27 -0000 1.58
--- symfile.c 16 Apr 2002 13:18:36 -0000
*************** static void cashier_psymtab (struct part
*** 120,125 ****
--- 120,127 ----
bfd *symfile_bfd_open (char *);
+ int get_section_index (struct objfile *, char *);
+
static void find_sym_fns (struct objfile *);
static void decrement_reading_symtab (void *);
*************** symfile_bfd_open (char *name)
*** 1113,1118 ****
--- 1115,1132 ----
bfd_errmsg (bfd_get_error ()));
}
return (sym_bfd);
+ }
+
+ /* Return the section index for the given section name. Return -1 if
+ the section was not found. */
+ int
+ get_section_index (struct objfile *objfile, char *section_name)
+ {
+ asection *sect = bfd_get_section_by_name (objfile->obfd, section_name);
+ if (sect)
+ return sect->index;
+ else
+ return -1;
}
/* Link a new symtab_fns into the global symtab_fns list. Called on gdb
Index: mdebugread.c
===================================================================
RCS file: /cvs/src/src/gdb/mdebugread.c,v
retrieving revision 1.24
diff -c -3 -p -r1.24 mdebugread.c
*** mdebugread.c 19 Mar 2002 19:00:03 -0000 1.24
--- mdebugread.c 16 Apr 2002 13:18:36 -0000
*************** struct symloc
*** 143,149 ****
|| (sc) == scPData \
|| (sc) == scXData)
#define SC_IS_COMMON(sc) ((sc) == scCommon || (sc) == scSCommon)
! #define SC_IS_BSS(sc) ((sc) == scBss || (sc) == scSBss)
#define SC_IS_UNDEF(sc) ((sc) == scUndefined || (sc) == scSUndefined)
\f
/* Various complaints about symbol reading that don't abort the process */
--- 143,150 ----
|| (sc) == scPData \
|| (sc) == scXData)
#define SC_IS_COMMON(sc) ((sc) == scCommon || (sc) == scSCommon)
! #define SC_IS_BSS(sc) ((sc) == scBss)
! #define SC_IS_SBSS(sc) ((sc) == scSBss)
#define SC_IS_UNDEF(sc) ((sc) == scUndefined || (sc) == scSUndefined)
\f
/* Various complaints about symbol reading that don't abort the process */
*************** parse_partial_symbols (struct objfile *o
*** 2425,2450 ****
--- 2426,2497 ----
ms_type = mst_bss;
svalue += ANOFFSET (objfile->section_offsets, SECT_OFF_BSS (objfile));
}
+ else if (SC_IS_SBSS (ext_in->asym.sc))
+ {
+ ms_type = mst_bss;
+ svalue += ANOFFSET (objfile->section_offsets,
+ get_section_index (objfile, ".sbss"));
+ }
else
ms_type = mst_abs;
break;
case stLabel:
/* Label */
+
+ /* On certain platforms, some extra label symbols can be
+ generated by the linker. One possible usage for this kind
+ of symbols is to represent the address of the begining of a
+ given section. For instance, on Tru64 5.1, the address of
+ the _ftext label is the start address of the .text section.
+
+ The storage class of these symbols is usually directly
+ related to the section to which the symbol refers. For
+ instance, on Tru64 5.1, the storage class for the _fdata
+ label is scData, refering to the .data section.
+
+ It is actually possible that the section associated to the
+ storage class of the label does not exist. On True64 5.1
+ for instance, the libm.so shared library does not contain
+ any .data section, although it contains a _fpdata label
+ which storage class is scData... Since these symbols are
+ usually useless for the debugger user anyway, we just
+ discard these symbols.
+ */
+
if (SC_IS_TEXT (ext_in->asym.sc))
{
+ if (objfile->sect_index_text == -1)
+ continue;
+
ms_type = mst_file_text;
svalue += ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
}
else if (SC_IS_DATA (ext_in->asym.sc))
{
+ if (objfile->sect_index_data == -1)
+ continue;
+
ms_type = mst_file_data;
svalue += ANOFFSET (objfile->section_offsets, SECT_OFF_DATA (objfile));
}
else if (SC_IS_BSS (ext_in->asym.sc))
{
+ if (objfile->sect_index_bss == -1)
+ continue;
+
ms_type = mst_file_bss;
svalue += ANOFFSET (objfile->section_offsets, SECT_OFF_BSS (objfile));
}
+ else if (SC_IS_SBSS (ext_in->asym.sc))
+ {
+ const int sbss_sect_index = get_section_index (objfile, ".sbss");
+
+ if (sbss_sect_index == -1)
+ continue;
+
+ ms_type = mst_file_bss;
+ svalue += ANOFFSET (objfile->section_offsets, sbss_sect_index);
+ }
else
ms_type = mst_abs;
break;
next prev parent reply other threads:[~2002-04-16 17:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-12 3:19 Joel Brobecker
2002-04-12 3:22 ` Joel Brobecker
2002-04-14 15:39 ` Elena Zannoni
2002-04-16 10:40 ` Joel Brobecker [this message]
2002-04-19 9:15 ` Elena Zannoni
2002-04-22 3:21 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020416193952.A1404@act-europe.fr \
--to=brobecker@act-europe.fr \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox