[RFA] Fix uninitialized section index internal error

[Joel Brobecker <brobecker@act-europe.fr>]

Hi,

  I'm sorry I've been overwhelmed by other tasks in the past weeks, and
could not pursue this issue. I am resubmitting this patch again. Please
let me know if I am not following the right procedure.

While working with gdb on Tru64 5.1, we noticed the following internal
error sometimes happening at the begining of a gdb session:

| gdb/mdebugread.c:2448: gdb-internal-error: Section index is uninitialized
|
| An internal GDB error was detected.  This may make further
| debugging unreliable.  Continue this debugging session? (y or n) n

To reproduce the problem, simply compile the following C program:

mach.c:
<<
int
main (void)
{
   return 0;
};
>>

Make sure libmach is linked in when building the program:
% gcc -o mach mach.c -lmach

After for investigation, I found that gdb was looking for a symbol in
the .bss section of libmach.so, but there is none (which explains why
the section index is not initialized). Instead, there is a .sbss
section, where the symbol is localized.

I modified default_symfile_offsets () to use the .sbss section if the
.bss one does not exist. In that change, I am assuming that a bss and a
sbss section are mutually exclusive.

This change has been integrated in ACT's version of gdb a few months
ago, and has worked well so far.

Here is the change log:

2001-06-07  J. Brobecker <brobecker@act-europe.fr>

        * symfile.c (default_symfile_offsets): use the .sbss section in
        place of the .bss section when the latter does not exist.

-- 
Joel
From brobecker@act-europe.fr Thu Jun 07 06:19:00 2001
From: Joel Brobecker <brobecker@act-europe.fr>
To: gdb-patches@sources.redhat.com
Subject: [RFA] Add new comment
Date: Thu, 07 Jun 2001 06:19:00 -0000
Message-id: <20010607151935.D24983@act-europe.fr>
X-SW-Source: 2001-06/msg00120.html
Content-length: 510

Hi,

  in solib-osf.c, the osf_in_dynsym_resolve_code function has been recently
added. While porting gdb to Tru64 5.1 on our side, we did exactly the same,
except that we added some comments explaining the consequences of always
returning 0. I am hoping that you find this comment useful.

Here is the ChangeLog entry:

2001-06-07  J. Brobecker <brobecker@act-europe.fr>

        * solib-osf.c (osf_in_dynsym_resolve_code): Add a comment explaining
          the consequences of always returning 0.

-- 
Joel
From ac131313@cygnus.com Thu Jun 07 07:29:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: compare strings carefully in gdbarch.sh
Date: Thu, 07 Jun 2001 07:29:00 -0000
Message-id: <3B1F7C72.2010203@cygnus.com>
References: <20010606181831.CDD365E9CB@zwingli.cygnus.com>
X-SW-Source: 2001-06/msg00121.html
Content-length: 634

> Isn't that amazing?  If it's the only thing there, then `[' knows it's
> not a unary operator, and apparently applies the "true if string not
> null" interpretation to it.  But if it's followed by something, then
> it assumes it's an operator.

$ [ -1 ] && echo "hi"
hi
$ [ -1 -a -2 ] && echo "hi"
hi


It's more of a compatibility issue.  The script works on Solaris and *BSD.



> 2001-06-06  Jim Blandy  <jimb@redhat.com>
> 
> * gdbarch.sh: Make sure that '[' doesn't interpret interesting
> 	variable values as operators.

Yes, ok. Doug Evans posted a similar patch but that one had massive 
offsets so I dropped it.

	Andrew