Problem with 2000-05-05 elfread.c change

Problem with 2000-05-05 elfread.c change

[Peter.Schauer]

Problem with 2000-05-05 elfread.c change

This change:

2000-05-05  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>

        * elfread.c (elf_symtab_read): The calculation of 'offset' 
        must be done for each symbol, not just once. The index 
        used must be the index of the section where 'sym' resides,
        not .text.

causes subtle and difficult to track down problems with some gcc compiled C++
executables.
These executables have a very large number of .gnu.linkonce sections
when using native ld on Solaris (I have not yet tried GNU ld, but GDB
should work with executables generated with native ld).
As an example, testsuite/gdb.c++/virtfunc contains 95 sections, our large
C++ application 2750 sections.

The large number of sections causes an indexing beyond the bounds of the
offsets array in the ANOFFSET macro, which does no bounds checking.
So intermittent garbage is obtained for the offset value, causing
symbols to obtain the wrong address.


I hope that you have access to a GNU Solaris toolchain using native ld.

You should then be able to verify the problem by applying the ANOFFSET
bounds checking kludge below (can't use SECT_OFF_MAX, because not all users
of ANOFFSET include gdb-stabs.h).

Run the resulting GDB on testsuite/gdb.c++/virtfunc and watch it die...

*** ./symtab.h.orig	Fri Sep 15 21:27:33 2000
--- ./symtab.h	Fri Sep 29 23:22:48 2000
***************
*** 831,837 ****
  
  #define	ANOFFSET(secoff, whichone) \
     ((whichone == -1) ? \
!     (internal_error ("Section index is uninitialized"), -1) : secoff->offsets[whichone])
  
  /* The maximum possible size of a section_offsets table.  */
  
--- 831,840 ----
  
  #define	ANOFFSET(secoff, whichone) \
     ((whichone == -1) ? \
!     (internal_error ("Section index is uninitialized"), -1) : \
!      ((whichone >= 40) ? \
!       (internal_error ("Section index out of bounds"), -1) : \
!        secoff->offsets[whichone]))
  
  /* The maximum possible size of a section_offsets table.  */

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de

Re: Problem with 2000-05-05 elfread.c change

[Elena Zannoni]

Peter.Schauer writes:

I believe you. I was working on getting rid of that limit by
allocating stuff dynamically for the sections, but I didn't finish
it. Maybe I can find some time soon to finish it, but cannot guarantee
it. I'll see what I can do.
The change in elfread.c is however necessary to fix other problems.

Sorry.

Elena


 > Problem with 2000-05-05 elfread.c change
 > 
 > This change:
 > 
 > 2000-05-05  Elena Zannoni  <ezannoni@kwikemart.cygnus.com>
 > 
 >         * elfread.c (elf_symtab_read): The calculation of 'offset' 
 >         must be done for each symbol, not just once. The index 
 >         used must be the index of the section where 'sym' resides,
 >         not .text.
 > 
 > causes subtle and difficult to track down problems with some gcc compiled C++
 > executables.
 > These executables have a very large number of .gnu.linkonce sections
 > when using native ld on Solaris (I have not yet tried GNU ld, but GDB
 > should work with executables generated with native ld).
 > As an example, testsuite/gdb.c++/virtfunc contains 95 sections, our large
 > C++ application 2750 sections.
 > 
 > The large number of sections causes an indexing beyond the bounds of the
 > offsets array in the ANOFFSET macro, which does no bounds checking.
 > So intermittent garbage is obtained for the offset value, causing
 > symbols to obtain the wrong address.
 > 
 > 
 > I hope that you have access to a GNU Solaris toolchain using native ld.
 > 
 > You should then be able to verify the problem by applying the ANOFFSET
 > bounds checking kludge below (can't use SECT_OFF_MAX, because not all users
 > of ANOFFSET include gdb-stabs.h).
 > 
 > Run the resulting GDB on testsuite/gdb.c++/virtfunc and watch it die...
 > 
 > *** ./symtab.h.orig	Fri Sep 15 21:27:33 2000
 > --- ./symtab.h	Fri Sep 29 23:22:48 2000
 > ***************
 > *** 831,837 ****
 >   
 >   #define	ANOFFSET(secoff, whichone) \
 >      ((whichone == -1) ? \
 > !     (internal_error ("Section index is uninitialized"), -1) : secoff->offsets[whichone])
 >   
 >   /* The maximum possible size of a section_offsets table.  */
 >   
 > --- 831,840 ----
 >   
 >   #define	ANOFFSET(secoff, whichone) \
 >      ((whichone == -1) ? \
 > !     (internal_error ("Section index is uninitialized"), -1) : \
 > !      ((whichone >= 40) ? \
 > !       (internal_error ("Section index out of bounds"), -1) : \
 > !        secoff->offsets[whichone]))
 >   
 >   /* The maximum possible size of a section_offsets table.  */
 > 
 > -- 
 > Peter Schauer			pes@regent.e-technik.tu-muenchen.de

Re: Problem with 2000-05-05 elfread.c change

[Peter.Schauer]

I definitely think this has to be fixed for GDB 5.1 though.

> Peter.Schauer writes:
> 
> I believe you. I was working on getting rid of that limit by
> allocating stuff dynamically for the sections, but I didn't finish
> it. Maybe I can find some time soon to finish it, but cannot guarantee
> it. I'll see what I can do.
> The change in elfread.c is however necessary to fix other problems.
> 
> Sorry.
> 
> Elena

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de

Re: Problem with 2000-05-05 elfread.c change

[Elena Zannoni]

Peter.Schauer writes:
 > I definitely think this has to be fixed for GDB 5.1 though.

That's probably doable.

Elena

 > 
 > > Peter.Schauer writes:
 > > 
 > > I believe you. I was working on getting rid of that limit by
 > > allocating stuff dynamically for the sections, but I didn't finish
 > > it. Maybe I can find some time soon to finish it, but cannot guarantee
 > > it. I'll see what I can do.
 > > The change in elfread.c is however necessary to fix other problems.
 > > 
 > > Sorry.
 > > 
 > > Elena
 > 
 > -- 
 > Peter Schauer			pes@regent.e-technik.tu-muenchen.de

CVS GDB and Register Numbers and Remote Protocol.

[Steven Johnson]

I am using a very recent version of GDB from CVS (only a couple of days
old).

I Have a strange thing happening with register numbers and my remote
target (A
Motorola PowerPC MPC860 board). The problem is that
the offsets needed for the response to the 'g' request to read all
registers
are not the same as those sent in the 'P' packet to
change them. This is really bad and confusing. It makes the stub a mess
trying
to cope with it. What I have traced it to is:

The response to 'g' needs to have the registers reported in the same
order as
info all-registers. No Problem.

But the 'P' packet sends the register number as the offset of the
register in
the table registers_860. This Normally would be fine,
but there are lots of spurious registers in this table for the mpc860,
and some
of them do not show in the info all-registers
display. The Prime culprits being PPC_UISA_SPRS where there is a reg
placeholder R0 at the end of the entry which is a non existent
register and is never shown. (This offsets all following registers by 1)
and
then there is PPC_OEA_SPRS with R64(asr) which is not
present on 32 bit architectures. which again offsets all following
registers by
1. So if you were to look at info registers you
would see that $der is register number 125, but the 'P' packet writes to
register number 127 which is $countb (according to info
all-registers).

If i put these extra un-defined registers in the 'g' response then
info-registers no longer shows the correct information, shifiting
all data down by 1 after each of these. (But the 'P' packet now has the
right
numbers).

What do I do. This seems very messy. Further, the way the registers are
defined
for the MPC860, there are 75 unimplemented registers
defined in the registers_860 structure (32 floating point registers and
43undefined SPR's). Thats 44% of unuseful crap declared.

Would anyone have any objections to me culling the 74 useless
definitions from
this structure. This would be the most immediate fix,
Im not sure what should be correct behaviour for a stub thugh. What is
being
handled incorrectly by GDB, 'g' or 'P'? I have no
problems effecting a fix, but there are 2 ways it could be achieved.

Thoughts Anyone?

Steven Johnson