This is the mail archive of the gdb@sourceware.cygnus.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]

xcoff anybody?



I am trying to fix the section offsets /add-symbol-file thing.
I am quite perplexed by xcoffread.c however.

xcoffread.c is the only reader that uses its own function
(xcoff_symfile_offsets() ) to set up the section offsets in the
objfile, all the other readers (except for another one about which
I'll send e-mail later) use the same function:
default_symfile_offsets().

The function xcoff_symfile_offsets() sets all the offsets to 0
assuming that a later call to objfile_relocate will do the right
thing.
Here is the relevant code from xcoffread.c:

  /* syms_from_objfile kindly subtracts from addr the bfd_section_vma
     of the .text section.  This strikes me as wrong--whether the
     offset to be applied to symbol reading is relative to the start
     address of the section depends on the symbol format.  In any
     event, this whole "addr" concept is pretty broken (it doesn't
     handle any section but .text sensibly), so just ignore the addr
     parameter and use 0.  rs6000-nat.c will set the correct section
     offsets via objfile_relocate.  */
  for (i = 0; i < objfile->num_sections; ++i)
    ANOFFSET (objfile->section_offsets, i) = 0;

vmap_symtab() is the function that calls objfile_relocate. 

One of the arguments to xcoff_symfile_offsets() is 'addrs' which
contains the values supplied by the user to the add-symbol-file
command. This argumetns is ignored by xcoff_symfile_offsets(), and it
gets lost forever, it is not propagated to some other function for
later use. The values used by objfile_relocate are different ones,
probably derived from the objfile itself.

So it seems to me that there is no way to have the user provide
addresses for the various sections vis add-symbol-file in the
xcoff. Is this really the case?

Any suggestion/preference as how to proceed here? Should we just leave
xcoff alone for the moment? 


Another thing:
while grepping for vmap_symtab, I noticed the following:

rs6000-nat.c:68:vmap_symtab PARAMS ((struct vmap *));
rs6000-nat.c:335:vmap_symtab (vp)
rs6000-nat.c:460:      vmap_symtab (vp);
rs6000-nat.c:555:	  vmap_symtab (vp);
rs6000-nat.c:782:      vmap_symtab (vp);
xcoffsolib.c:119:	  vmap_symtab (vp, 0, 0); <<<<<< Wrong # of parameters.

OK to fix this?



Elena

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