public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* xcoff anybody?
@ 2000-04-18  7:59 Elena Zannoni
  2000-04-18 11:32 ` Stan Shebs
       [not found] ` <200004191023.MAA32246@reaktor.regent.e-technik.tu-muenchen.de>
  0 siblings, 2 replies; 4+ messages in thread
From: Elena Zannoni @ 2000-04-18  7:59 UTC (permalink / raw)
  To: gdb

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: xcoff anybody?
  2000-04-18  7:59 xcoff anybody? Elena Zannoni
@ 2000-04-18 11:32 ` Stan Shebs
  2000-04-18 17:57   ` Elena Zannoni
       [not found] ` <200004191023.MAA32246@reaktor.regent.e-technik.tu-muenchen.de>
  1 sibling, 1 reply; 4+ messages in thread
From: Stan Shebs @ 2000-04-18 11:32 UTC (permalink / raw)
  To: Elena Zannoni; +Cc: gdb

Elena Zannoni wrote:
> 
> 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().

xcoff_symfile_offsets is probably a no-op - for AIX you don't
know where things really are until runtime, when you make a ptrace
call to get the location data and then pass it to objfile_relocate.
(Yes, this would make gdbserver for AIX a little tricky!)  A long
time ago I did some basic work to disentangle xcoff reading from
AIX native support, for the benefit of the Mac port, but it's
still not the case that xcoff is just another format that works
like all the others.

Unless cross-debugging for AIX is important all of a sudden, I
would say to keep it simple and not try to support arbitrary
relocation ability - just issue an error or something.

> 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?

Fine by me.  It's probably my fault, I vaguely remember tinkering
with vmap_symtab at some point.

Stan

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: xcoff anybody?
  2000-04-18 11:32 ` Stan Shebs
@ 2000-04-18 17:57   ` Elena Zannoni
  0 siblings, 0 replies; 4+ messages in thread
From: Elena Zannoni @ 2000-04-18 17:57 UTC (permalink / raw)
  To: shebs; +Cc: Elena Zannoni, gdb

Stan Shebs writes:
 > Elena Zannoni wrote:
 > > 
 > > 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().
 > 
 > xcoff_symfile_offsets is probably a no-op - for AIX you don't
 > know where things really are until runtime, when you make a ptrace
 > call to get the location data and then pass it to objfile_relocate.
 > (Yes, this would make gdbserver for AIX a little tricky!)  A long
 > time ago I did some basic work to disentangle xcoff reading from
 > AIX native support, for the benefit of the Mac port, but it's
 > still not the case that xcoff is just another format that works
 > like all the others.
 > 
 > Unless cross-debugging for AIX is important all of a sudden, I
 > would say to keep it simple and not try to support arbitrary
 > relocation ability - just issue an error or something.
 > 

Good. That would make my life easier.

 > > 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?
 > 
 > Fine by me.  It's probably my fault, I vaguely remember tinkering
 > with vmap_symtab at some point.
 > 

Will fix.

Elena

 > Stan
 > 

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: xcoff anybody?
       [not found] ` <200004191023.MAA32246@reaktor.regent.e-technik.tu-muenchen.de>
@ 2000-04-19  6:39   ` Elena Zannoni
  0 siblings, 0 replies; 4+ messages in thread
From: Elena Zannoni @ 2000-04-19  6:39 UTC (permalink / raw)
  To: gdb-patches, gdb

I committed the following:

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

        * xcoffsolib.c (solib_add): Fix call to vmap_symtab().

Index: xcoffsolib.c
===================================================================
RCS file: /cvs/src/src/gdb/xcoffsolib.c,v
retrieving revision 1.1.1.4
diff -u -p -r1.1.1.4 xcoffsolib.c
--- xcoffsolib.c        1999/10/05 23:09:04     1.1.1.4
+++ xcoffsolib.c        2000/04/19 13:07:01
@@ -116,7 +116,7 @@ solib_add (arg_string, from_tty, target)
 
          syms_from_objfile (obj, NULL, 0, 0);
          new_symfile_objfile (obj, 0, 0);
-         vmap_symtab (vp, 0, 0);
+         vmap_symtab (vp);
          printf_unfiltered ("Done.\n");
          loaded = vp->loaded = 1;
        }

Elena

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-04-19  6:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-18  7:59 xcoff anybody? Elena Zannoni
2000-04-18 11:32 ` Stan Shebs
2000-04-18 17:57   ` Elena Zannoni
     [not found] ` <200004191023.MAA32246@reaktor.regent.e-technik.tu-muenchen.de>
2000-04-19  6:39   ` Elena Zannoni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).