From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFA] Fix uninitialized section index internal error Date: Thu, 07 Jun 2001 06:08:00 -0000 Message-id: <20010607150845.C24983@act-europe.fr> X-SW-Source: 2001-06/msg00119.html 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 * 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 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 * 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 To: Jim Blandy 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 > > * 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