Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Duffek <nsd@redhat.com>
To: kevinb@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] osfsolib.c: support Tru64 5.x
Date: Mon, 14 May 2001 18:34:00 -0000	[thread overview]
Message-ID: <200105150144.f4F1i2208435@rtl.cygnus.com> (raw)
In-Reply-To: <1010513070637.ZM31193@ocotillo.lan>

On 13-May-2001, Kevin Buettner wrote:

>Is there any chance that osfsolib.c could be reworked into a solib.c
>backend?

Okay, I've just finished doing that.  It's nice to delete so much
duplicated code; the new file is 60% the size of the old one.

Is there any pending gdbint.texinfo documentation on how to implement
shared library support using solib.c?  If not, I volunteer to write a
brief explanation, while it's fresh in my mind.

I ran into a couple of problems:

1. It's necessary for the target_so_ops.current_sos callback to zero at
least the so_list.section field of each element it returns.  Otherwise,
solib_map_sections() passes a bogus pointer to build_section_table(),
which frees the bogus pointer.

What do you think about a patch like this?

Index: gdb/solist.h
===================================================================
diff -up gdb/solist.h gdb/solist.h
--- gdb/solist.h	Mon May 14 21:17:56 2001
+++ gdb/solist.h	Mon May 14 21:17:46 2001
@@ -52,7 +52,9 @@ struct so_list
 
     /* The following fields of the structure are built from
        information gathered from the shared object file itself, and
-       are initialized when we actually add it to our symbol tables.  */
+       are set when we actually add it to our symbol tables.
+
+       current_sos must initialize these fields to 0.  */
 
     bfd *abfd;
     char symbols_loaded;	/* flag: symbols read in yet? */

2. Because Tru64 doesn't use ELF binaries, "info sharedlibrary"
incorrectly infers the address size to be 32 bits, so output address
fields are too narrow:

  (gdb) inf shared
  From        To          Syms Read   Shared Object Library
  0x3ff800cd8100x3ff801ca290Yes         /usr/shlib/libc.so
  (gdb) 

Some possible fixes:
  (a) Default to 64 instead of 32 bits.
  (b) Use something like bfd_arch_bits_per_address(exec_bfd) instead of
      or in addition to bfd_get_arch_size (exec_bfd).

I'll post the new osfsolib.c patch as soon as I finish regression-testing
it.

Nick


  reply	other threads:[~2001-05-14 18:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-12 16:45 Nicholas Duffek
2001-05-13  0:06 ` Kevin Buettner
2001-05-14 18:34   ` Nick Duffek [this message]
2001-05-15 17:02     ` Kevin Buettner
2001-05-24 18:58       ` Nick Duffek
     [not found] <1010525224132.ZM16493@ocotillo.lan>
2001-05-25 17:37 ` Nick Duffek
2001-05-25 18:08   ` Kevin Buettner
2001-05-25 17:55 ` Nick Duffek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200105150144.f4F1i2208435@rtl.cygnus.com \
    --to=nsd@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kevinb@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox