From: Kevin Buettner <kevinb@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] osfsolib.c: support Tru64 5.x
Date: Tue, 15 May 2001 17:02:00 -0000 [thread overview]
Message-ID: <1010516000146.ZM9797@ocotillo.lan> (raw)
In-Reply-To: <200105150144.f4F1i2208435@rtl.cygnus.com>
On May 14, 9:44pm, Nick Duffek 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.
Very cool. Thanks for doing this.
> 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 have nothing planned. I think it'd be great if you'd write up the
documentation.
> 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? */
Good catch. Please check this in.
> 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).
Option (b) sounds better to me.
> I'll post the new osfsolib.c patch as soon as I finish regression-testing
> it.
Cool. I'm looking forward to seeing it.
Thanks,
Kevin
next prev parent reply other threads:[~2001-05-15 17:02 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
2001-05-15 17:02 ` Kevin Buettner [this message]
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=1010516000146.ZM9797@ocotillo.lan \
--to=kevinb@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=nsd@redhat.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