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
next prev 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