This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
xcoff anybody?
- To: gdb at sourceware dot cygnus dot com
- Subject: xcoff anybody?
- From: Elena Zannoni <ezannoni at cygnus dot com>
- Date: Tue, 18 Apr 2000 10:59:35 -0400 (EDT)
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