From: Joel Brobecker <brobecker@ACT-Europe.FR>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Uninitialized section index internal error on Tru64 5.1
Date: Fri, 12 Apr 2002 03:22:00 -0000 [thread overview]
Message-ID: <20020412122250.F16134@act-europe.fr> (raw)
In-Reply-To: <20020412121941.E16134@act-europe.fr>; from brobecker@ACT-Europe.FR on Fri, Apr 12, 2002 at 12:19:41PM +0200
[-- Attachment #1: Type: text/plain, Size: 268 bytes --]
> The following patch fixes many regressions in the testsuite:
> Summary 1 2
> FAIL 1644 792
> PASS 4388 6990
> XFAIL 59 149
> XPASS 1 3
Sorry, the patch is attached, this time.
What a fool sometimes...
--
Joel
[-- Attachment #2: mdebugread.c.diff --]
[-- Type: text/plain, Size: 4716 bytes --]
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 12 Apr 2002 10:02:08 -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 */
*************** static int found_ecoff_debugging_info;
*** 327,332 ****
--- 328,335 ----
/* Forward declarations */
+ static int get_section_index (struct objfile *, char *);
+
static int upgrade_type (int, struct type **, int, union aux_ext *,
int, char *);
*************** is_pending_symbol (FDR *fh, char *sh)
*** 637,642 ****
--- 640,657 ----
return p;
}
+ /* Return the section index for the given section name. Return -1 if
+ the section was not found. */
+ static 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;
+ }
+
/* Add a new symbol SH of type T */
static void
*************** parse_partial_symbols (struct objfile *o
*** 2425,2450 ****
--- 2440,2511 ----
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-12 10:22 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 [this message]
2002-04-14 15:39 ` Elena Zannoni
2002-04-16 10:40 ` Joel Brobecker
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=20020412122250.F16134@act-europe.fr \
--to=brobecker@act-europe.fr \
--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