Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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;

  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