Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 7/8] ia64-hpux: unwinding bsp value from system call
Date: Wed, 29 Dec 2010 12:05:00 -0000	[thread overview]
Message-ID: <201012291042.14627.pedro@codesourcery.com> (raw)
In-Reply-To: <20101229032848.GE2396@adacore.com>

On Wednesday 29 December 2010 03:28:48, Joel Brobecker wrote:
> > What is the underlying object you're getting those values from?
> > I understood it to be whatever object TT_LWP_RUREGS accesses?
> > You seem to call it save_state_t?  Why not TARGET_OBJECT_HPUX_RUREGS
> > or TARGET_OBJECT_HPUX_SAVE_STATE, or something along those lines?
> > Then, the offset, and length passed to target_xfer would the
> > the offset and length you're currently passing to
> > ia64_hpux_read_register_from_save_state_t.  This would allow
> > (if useful) exporting this object similarly to the $_siginfo and
> > $_tlb objects.
> 
> I cannot determine the offset from the tdep code.  The offset is
> is a obtained by including one of the system hearders.

Before you dismiss this completely on that
ground, looking at hppa-hpux-tdep.c, I see:

 /* Bit in the `ss_flag' member of `struct save_state' that indicates
    that the 64-bit register values are live.  From
    <machine/save_state.h>.  */
 #define HPPA_HPUX_SS_WIDEREGS		0x40

 /* Offsets of various parts of `struct save_state'.  From
    <machine/save_state.h>.  */
 #define HPPA_HPUX_SS_FLAGS_OFFSET	0
 #define HPPA_HPUX_SS_NARROW_OFFSET	4
 #define HPPA_HPUX_SS_FPBLOCK_OFFSET 	256
 #define HPPA_HPUX_SS_WIDE_OFFSET        640

 /* The size of `struct save_state.  */
 #define HPPA_HPUX_SAVE_STATE_SIZE	1152

 /* The size of `struct pa89_save_state', which corresponds to PA-RISC
    1.1, the lowest common denominator that we support.  */
 #define HPPA_HPUX_PA89_SAVE_STATE_SIZE	512

...

 * Bit in the `ss_flag' member of `struct save_state' that indicates
    the state was saved from a system call.  From
    <machine/save_state.h>.  */
 #define HPPA_HPUX_SS_INSYSCALL	0x02


And e.g., see hppa_hpux_supply_save_state.

When you implement core support for ia64-hpux, if done
right (in tdep code, host-independent, supporting cross core
debugging), you'll need to hardcode these offsets anyway.  It
looks like HPUX dumps each LWP's save_save in the cores.  These
offset are usually practically part of the ABI.

Just adding this as a data point.

-- 
Pedro Alves


  reply	other threads:[~2010-12-29 10:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-28  4:43 Porting GDB to ia64-hpux Joel Brobecker
2010-12-28  4:43 ` [PATCH 4/8] libunwind-frame.c: handle functions with no minimal symbol/debug info Joel Brobecker
2010-12-28  4:43 ` [PATCH 1/8] Add a big-endian version of the ia64-ext floatformat Joel Brobecker
2010-12-28  4:43 ` [PATCH 2/8] small integral parameters and return values Joel Brobecker
2010-12-28  4:44 ` [PATCH 3/8] Make sure __LITTLE_ENDIAN/__BIG_ENDIAN are defined in libunwind-frame.c Joel Brobecker
2010-12-28  4:44 ` [PATCH 5/8] inf-ttrace: Determine attached process LWP immediately after attaching Joel Brobecker
2010-12-28 11:04   ` Pedro Alves
2010-12-28 11:26     ` Joel Brobecker
2010-12-28  4:44 ` [PATCH 6/8] port GDB to ia64-hpux (native) Joel Brobecker
2011-01-11 23:26   ` Steve Ellcey
2011-01-12  1:26     ` Joel Brobecker
2011-01-12 16:57       ` Steve Ellcey
2011-01-12 20:11         ` Joel Brobecker
2011-01-13  1:01     ` Joel Brobecker
2011-01-13  5:13       ` Steve Ellcey
     [not found]       ` <1299014508.30497.20.camel@hpsje.cup.hp.com>
     [not found]         ` <20110302044549.GU2513@adacore.com>
     [not found]           ` <1299171098.30497.88.camel@hpsje.cup.hp.com>
     [not found]             ` <20110303172717.GJ2513@adacore.com>
     [not found]               ` <1299173882.30497.114.camel@hpsje.cup.hp.com>
2011-06-17 16:30                 ` Joel Brobecker
2011-01-13 18:07   ` Joel Brobecker
2010-12-28  4:54 ` [PATCH 7/8] ia64-hpux: unwinding bsp value from system call Joel Brobecker
2010-12-28 11:35   ` Pedro Alves
2010-12-28 12:01     ` Joel Brobecker
2010-12-28 16:17       ` Pedro Alves
2010-12-29  5:49         ` Joel Brobecker
2010-12-29 12:05           ` Pedro Alves [this message]
2010-12-29 13:16             ` Joel Brobecker
2010-12-31 18:15             ` Joel Brobecker
2010-12-28 15:29     ` [RFA/commit] Add documentation for TARGET_OBJECT_OSDATA Joel Brobecker
2010-12-28 15:46       ` Pedro Alves
2010-12-29  3:29       ` Joel Brobecker
2010-12-28  5:00 ` [PATCH 8/8] [ia64-hpux] inferior function call support Joel Brobecker
2010-12-31 19:18   ` Joel Brobecker
2011-01-13 16:53 ` Porting GDB to ia64-hpux Joel Brobecker

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=201012291042.14627.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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