Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Greg Alexander <greg@dignus.com>
Cc: gdb-patches@sources.redhat.com, David Rivers <rivers@dignus.com>,
	barrow_dj@yahoo.com
Subject: Re: *gregset_t misuse (was Re: S390 GDB patch for Dignus Linux/390 compiler support)
Date: Mon, 18 Mar 2002 08:20:00 -0000	[thread overview]
Message-ID: <20020318111934.A1499@nevyn.them.org> (raw)
In-Reply-To: <200203181558.g2IFwG087850@greg.dignus.com>

On Mon, Mar 18, 2002 at 10:58:16AM -0500, Greg Alexander wrote:
> I'm having a hard time figuring out how exactly the ps_l{get,set}regs()
> and thread_db_{fetch,store}_registers() functions get used, but my
> proposal would be for them to use gdb_gregset_t instead of prgregset_t
> (so that gdb_gregset_t can be defined to a pointer type if necessary --
> prgregset_t is really an arch-specific type and should only be referenced
> inside of arch-aware files).  I also propose that fill_gregset() and

No.  ps_lgetregs is not a gdb-called function.  It's called from
libthread_db.so, which is provided by the system.  Its argument must be
a prgregset_t.  Therefore prgregset_t must also be a pointer or array type.

> It all comes down to the fact that gdb_gregset_t will probably be typedefed
> to prgregset_t or prgregset_t*, but never both!

Remember what I said?  From an i386-linux <sys/procfs.h>:

/* And the whole bunch of them.  We could have used `struct
   user_regs_struct' directly in the typedef, but tradition says that
   the register set is an array, which does have some peculiar
   semantics, so leave it that way.  */
#define ELF_NGREG (sizeof (struct user_regs_struct) / sizeof(elf_greg_t))
typedef elf_greg_t elf_gregset_t[ELF_NGREG];


S/390 needs to do the same thing.  It's very hard to compensate for an
incorrect prgregset_t, because of some peculiarities in the type system
of C w.r.t. arrays and pointer decay.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2002-03-18 16:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-15 13:11 S390 GDB patch for Dignus Linux/390 compiler support Greg Alexander
2002-03-15 13:57 ` Daniel Jacobowitz
2002-03-18  7:58   ` *gregset_t misuse (was Re: S390 GDB patch for Dignus Linux/390 compiler support) Greg Alexander
2002-03-18  8:20     ` Daniel Jacobowitz [this message]
2002-03-22 12:14     ` Michael Snyder
2002-04-07  9:28 ` S390 GDB patch for Dignus Linux/390 compiler support Andrew Cagney

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=20020318111934.A1499@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=barrow_dj@yahoo.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=greg@dignus.com \
    --cc=rivers@dignus.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