From: Andrew Cagney <ac131313@cygnus.com>
To: thorpej@wasabisystems.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH/RFC] Generic OS ABI handling for gdbarch
Date: Sun, 12 May 2002 22:20:00 -0000 [thread overview]
Message-ID: <3CDF4D07.2050805@cygnus.com> (raw)
In-Reply-To: <20020511212045.I3435@dr-evil.shagadelic.org>
> I started working on generic OS ABI handling for GDB today, lifting from
> the various duplicated bits of code in several targets.
>
> There are two pieces to the generic code:
>
> * OS ABI handlers. These are basically the same as the OS ABI
> handlers that exist on a per-target basis, but when they're
> registered, you now specify a bfd_architecture. Only one
> OS ABI can exist per bfd_architecture.
>
> * OS ABI "sniffers". These peek at a BFD with a given
> bfd_architecture/bfd_flavour and determine which OS ABI
> is correct for that BFD. Multiple sniffers can exist for
> a given bfd_architecture/bfd_flavour, e.g. one to sniff out
> NetBSD a.out, one for FreeBSD a.out, etc. If a sniffer
> registers w/ bfd_architecture of "unknown", it can sniff
> files of any architecture for its flavour.
>
> There is a generic ELF sniffer that uses EI_OSABI and note
> sections. (This is an example of an arch == "unknown"
> sniffer.)
>
> The first sniffer to return other than GDB_OSABI_UNKNOWN
> wins, so sniffers should be careful to only claim BFDs
> they're sure about.
>
> Tomorrow I'll make the Alpha and SH targets use the generic OS ABI
> framework as examples.
Yep, by me. And the target maintainers (arm, we're obsoleting WinCE),
perhaphs give it some of the week to stew.
Andrew
> +#ifndef OSABI_H
> +#define OSABI_H
struct gdbarch;
[Hmm, the include section of the doco, doesn't mention this.]
> +/* List of known OS ABIs. If you change this, make sure to update the
> + table in osabi.c. */
Suggest checking this in _initialize_osabi().
> +enum gdb_osabi
> +{
> + GDB_OSABI_UNKNOWN = 0, /* keep this first */
> +
> +/* Register an OS ABI sniffer. Each arch/flavour may have more than
> + one sniffer. This is used to e.g. differentiate one OS's a.out from
> + another. The first sniffer to return something other than
> + GDB_OSABI_UNKNOWN wins, so a sniffer should be careful to claim a file
> + only if it knows for sure what it is. */
What is the overhead of the ``sniff test''? Can I suggest checking all
regardless and then internal_error()ing on a double hit.
In the one hand, this means looking for trouble. On the other hand, it
is the only way we'll flush out some bugs before the next release.
nice,
Andrew
next prev parent reply other threads:[~2002-05-13 5:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-11 21:20 Jason R Thorpe
2002-05-12 10:06 ` Jason R Thorpe
2002-05-12 21:50 ` Eli Zaretskii
2002-05-12 22:00 ` Jason R Thorpe
2002-05-12 22:27 ` Eli Zaretskii
2002-05-12 22:20 ` Andrew Cagney [this message]
2002-05-13 8:49 ` Jason R Thorpe
2002-05-13 9:10 ` Andrew Cagney
2002-05-13 9:13 ` Jason R Thorpe
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=3CDF4D07.2050805@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb-patches@sources.redhat.com \
--cc=thorpej@wasabisystems.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