Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: Martin Gadbois <martin.gadbois@colubris.com>,
	gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Cross target core debugging: host=i386, Target=PPC
Date: Mon, 29 Jul 2002 14:59:00 -0000	[thread overview]
Message-ID: <1020729215359.ZM11339@localhost.localdomain> (raw)
In-Reply-To: Martin Gadbois <martin.gadbois@colubris.com> "[PATCH] Cross target core debugging: host=i386, Target=PPC" (Jul 29,  4:59pm)

On Jul 29,  4:59pm, Martin Gadbois wrote:

> diff -Naur gdb-5.2/gdb/gregset.h gdb-5.2-ppc-core/gdb/gregset.h
> --- gdb-5.2/gdb/gregset.h	Sun Feb 24 17:14:33 2002
> +++ gdb-5.2-ppc-core/gdb/gregset.h	Mon Jul 29 15:45:43 2002
> @@ -21,6 +21,20 @@
>  #ifndef GREGSET_H
>  #define GREGSET_H
>  
> +
> +#define ELF_NGREG	48	/* includes nip, msr, lr, etc. */
> +#define ELF_NFPREG	33	/* includes fpscr */
> +#define ELF_NVRREG	33	/* includes vscr */
> +
> +typedef unsigned long elf_greg_t;
> +typedef elf_greg_t elf_gregset_t[ELF_NGREG];
> +
> +typedef double elf_fpreg_t;
> +typedef elf_fpreg_t elf_fpregset_t[ELF_NFPREG];
> +
> +#define GDB_GREGSET_T elf_gregset_t
> +#define GDB_FPREGSET_T elf_fpregset_t
> +
>  #ifndef GDB_GREGSET_T
>  #define GDB_GREGSET_T gregset_t
>  #endif

This part will need some work.  (The other parts might too; I haven't
looked closely at them yet.)  Anyway, there are several problems here...

1) The constants ELF_NGREG, ELF_NFPREG, ELF_NVRREG will almost certainly
   be incorrect for other targets.

2) Defining elf_greg_t in terms of a long isn't portable.

3) Likewise, for elf_fpreg_t being defined in terms of a double.

For #1, why do these constants need to be put into a header file at
all.  Couldn't this knowledge be localized in the portion of the .c
file responsible for decoding the core format?

For #2 and #3, I think it's reasonably portable to define your data
types in terms of arrays of characters.  (Or perhaps in terms of
structs containing arrays of characters.  The struct representation
is perhaps more convenient in certain situations.)

Kevin


  reply	other threads:[~2002-07-29 21:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-29 14:06 Martin Gadbois
2002-07-29 14:59 ` Kevin Buettner [this message]
2002-07-29 16:45   ` Jason R Thorpe
2002-07-29 18:50     ` Daniel Jacobowitz
2002-07-30  8:35       ` Daniel Jacobowitz
2002-07-30  8:50         ` Martin Gadbois
2002-07-30 12:09           ` Daniel Jacobowitz
2002-07-30 10:47         ` Kevin Buettner
2002-07-30 10:52           ` Martin Gadbois
2002-07-30 11:24             ` Kevin Buettner
2002-07-30 10:55           ` Daniel Jacobowitz
2002-07-30 12:05           ` Daniel Jacobowitz
2002-07-30  5:53   ` Martin Gadbois
2002-07-30  6:43   ` Martin Gadbois
2002-07-29 15:07 ` Kevin Buettner
2002-07-30  5:30   ` Martin Gadbois

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=1020729215359.ZM11339@localhost.localdomain \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=martin.gadbois@colubris.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