This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH/RFC] Generic OS ABI handling for gdbarch


> 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]