Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: unwind support for Linux 2.6 vsyscall DSO
Date: Wed, 08 Oct 2003 23:53:00 -0000	[thread overview]
Message-ID: <20031008235350.GA20469@nevyn.them.org> (raw)
In-Reply-To: <3F847AF4.8090409@redhat.com>

On Wed, Oct 08, 2003 at 05:00:36PM -0400, Andrew Cagney wrote:
> >>- unpack an architecture's auxv
> >>- pack an architecture's auxv
> >
> >
> >This in fact differs with byte order and word size, not further by target.
> >So a generic utility function suffices for this.  If the responsibility for
> >packing and unpacking is in each target, they should all be able to use the
> >same utility function and stay about as simple as the block-reading target
> >code.  If the responsibility for unpacking lies with the caller of the
> >target function, then the single utility function suffices for all callers
> >(since then there is never a need for packing, only unpacking).
> 
> Unfortunatly, things aren't so simple :-(
> 
> Solaris:
> #define AT_DCACHEBSIZE  10      /* smallest data cache block size */
> #define AT_ICACHEBSIZE  11      /* smallest instruction cache block size */
> #define AT_UCACHEBSIZE  12      /* smallest unified cache block size */
> ...
> 
> GNU/Linux:
> #define AT_NOTELF 10    /* program is not ELF */
> #define AT_UID    11    /* real uid */
> #define AT_EUID   12    /* effective uid */
> ...
> 
> As with signals, the attribute indexes are per-os (and potentially per 
> ISA).  So core code will need to define an OS independant set of enums 
> and then map that onto the real numbers.
> 
> If I understand things correctly, the two driving needs are:
> 
> - being able to extract the value of AT_ENTRY, and AT_LINUX_<vsyscall 
> address>
> 
> - being able to obtain the entire AUXV so that it can be saved in a core 
> file
> 
> Would a per-os (technically per-architecture) SVR4 auxv lookup method 
> that was implement using a fixed to_query() work?

Sounds more or less good to me.  I don't think we need a generic
gdbarch method for querying auxv; more something like a
gdbarch_auxv_entry_point () and a gdbarch_auxv_sysinfo_dso_address ()?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  parent reply	other threads:[~2003-10-08 23:53 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-03  8:27 Roland McGrath
2003-10-03 23:44 ` Jim Blandy
2003-10-04  0:10   ` Roland McGrath
2003-10-04  7:28     ` Jim Blandy
2003-10-04 20:27       ` Roland McGrath
2003-10-04 21:14         ` Daniel Jacobowitz
2003-10-04 22:01           ` Roland McGrath
2003-10-04 23:28             ` Daniel Jacobowitz
2003-10-06 17:14         ` Jim Blandy
2003-10-06 19:35       ` Elena Zannoni
2003-10-06 19:31 ` Elena Zannoni
2003-10-06 20:24   ` Roland McGrath
2003-10-06 21:48     ` Elena Zannoni
2003-10-06 23:59       ` Roland McGrath
2003-10-07  0:13         ` Roland McGrath
2003-10-07  2:30           ` Elena Zannoni
2003-10-07  2:40             ` Roland McGrath
2003-10-07  2:47               ` Roland McGrath
2003-10-07  3:53           ` Andrew Cagney
2003-10-07  4:07             ` Daniel Jacobowitz
2003-10-07  4:17               ` Andrew Cagney
2003-10-07  4:28             ` Roland McGrath
2003-10-08  0:02               ` Michael Snyder
2003-10-08  0:46                 ` Roland McGrath
2003-10-08 18:27                   ` Andrew Cagney
2003-10-08 21:00               ` Andrew Cagney
2003-10-08 21:47                 ` Roland McGrath
2003-10-08 23:25                   ` Elena Zannoni
2003-10-09  0:45                     ` Roland McGrath
2003-10-08 23:10                 ` Elena Zannoni
2003-10-09  0:50                   ` Roland McGrath
2003-10-08 23:53                 ` Daniel Jacobowitz [this message]
2003-10-07  0:17         ` Daniel Jacobowitz
2003-10-07 23:54         ` Michael Snyder
2003-10-08  0:07           ` Roland McGrath
2003-10-07  4:43     ` Jim Blandy
2003-10-07  4:45       ` Roland McGrath
2003-10-09 19:58         ` Kevin Buettner
2003-10-09 20:02           ` Daniel Jacobowitz
2003-10-09 20:10             ` Jim Blandy
2003-10-09 22:20               ` Roland McGrath
2003-10-09 22:49                 ` Kevin Buettner
2003-10-10  0:12                   ` Michael Snyder
2003-10-11  1:44                   ` Roland McGrath
2003-10-09 23:04                 ` Kevin Buettner
2003-10-11  1:47                   ` Roland McGrath
2003-10-15  4:33                     ` Kevin Buettner
2003-10-09 20:21             ` Kevin Buettner
2003-10-09 20:23               ` Daniel Jacobowitz
2003-10-09 20:46                 ` Kevin Buettner
2003-10-09 22:32                   ` Roland McGrath
2003-10-09 22:46                     ` Kevin Buettner
2003-10-11  1:40                       ` Roland McGrath
2003-10-09 22:07           ` Roland McGrath
2003-10-09 22:32             ` Kevin Buettner
2003-10-07  3:33 Roland McGrath

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=20031008235350.GA20469@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.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