This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Re: should gdb require '.text' and '.data' sections? (alternate patch)


Fred Fish writes:
 > Josef Ezra <jezra@emc.com> previously submitted a patch for this
 > problem that assumes that the first text and data sections are
 > suitable alternatives for finding an explicit ".text" and ".data"
 > section.
 > 
 > Here is an alternate patch that is perfectly safe and fixes the
 > problem for the most common case, where all the section offsets are
 > zero.  I.E. it can only make things better until we can get rid
 > of the SECT_OFF_TEXT kludge completely.
 > 


Approved, 

Thanks
Elena

 > -Fred
 > 
 > 2002-04-24  Fred Fish  <fnf@redhat.com>
 > 
 > 	* symfile.c (default_symfile_offsets): Arrange for uninitialized
 > 	sect_index_xxx members to index the first slot in section_offsets
 > 	if all of the section_offsets are zero.
 > 
 > Index: symfile.c
 > ===================================================================
 > RCS file: /cvs/cvsfiles/devo/gdb/symfile.c,v
 > retrieving revision 1.223
 > diff -c -p -r1.223 symfile.c
 > *** symfile.c	2000/06/26 02:07:18	1.223
 > --- symfile.c	2002/04/24 15:25:16
 > *************** default_symfile_offsets (objfile, addrs)
 > *** 561,566 ****
 > --- 561,594 ----
 >     if (sect) 
 >       objfile->sect_index_rodata = sect->index;
 >   
 > +   /* This is where things get really weird...  We MUST have valid
 > +      indices for the various sect_index_* members or gdb will abort.
 > +      So if for example, there is no ".text" section, we have to
 > +      accomodate that.  Except when explicitly adding symbol files at
 > +      some address, section_offsets contains nothing but zeros, so it
 > +      doesn't matter which slot in section_offsets the individual
 > +      sect_index_* members index into.  So if they are all zero, it is
 > +      safe to just point all the currently uninitialized indices to the
 > +      first slot. */
 > + 
 > +   for (i = 0; i < objfile->num_sections; i++)
 > +     {
 > +       if (ANOFFSET (objfile->section_offsets, i) != 0)
 > + 	{
 > + 	  break;
 > + 	}
 > +     }
 > +   if (i == objfile->num_sections)
 > +     {
 > +       if (objfile->sect_index_text == -1)
 > + 	objfile->sect_index_text = 0;
 > +       if (objfile->sect_index_data == -1)
 > + 	objfile->sect_index_data = 0;
 > +       if (objfile->sect_index_bss == -1)
 > + 	objfile->sect_index_bss = 0;
 > +       if (objfile->sect_index_rodata == -1)
 > + 	objfile->sect_index_rodata = 0;
 > +     }
 >   }
 >   
 >   /* Process a symbol file, as either the main file or as a dynamically


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]