From: Will Newton <will.newton@linaro.org>
To: Tom Tromey <tromey@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH v2 0/9] share minimal symbols across objfiles
Date: Fri, 18 Oct 2013 10:32:00 -0000 [thread overview]
Message-ID: <CANu=DmjOE3GNh25k85pK72wBG7+2xwcF-V5LJhHYQHk-Hdr1vA@mail.gmail.com> (raw)
In-Reply-To: <1382032193-9115-1-git-send-email-tromey@redhat.com>
On 17 October 2013 18:49, Tom Tromey <tromey@redhat.com> wrote:
> This patch series changes minimal symbols to be independent of the
> program space, and then to be stored in the per-BFD object. That way,
> they can be shared by all objfiles referring to a given BFD. This
> saves memory, and, in the case of ELF, the time spent re-reading the
> symbols.
>
> In order to make a minimal symbol independent of the program space,
> the correct objfile offset must be applied when the symbol's address
> is computed. This series achieves that by introducing a two-argument
> form of SYMBOL_VALUE_ADDRESS (but done in a way to ensure that all
> errors will be caught at compile time); more fully completing the
> switchover to the use of bound minimal symbols; and finally by
> changing the definition of the new macro to apply the offsets.
>
> This is an update of a patch series I sent earlier:
>
> https://sourceware.org/ml/gdb-patches/2011-12/msg00470.html
>
> This version differs from the above in that:
>
> * There are no FIXMEs left
> * I updated all the minimal symbol readers
> * The use of bound minimal symbols (and the earlier removal of
> msymbol_objfile) solves any potential problem with dlmopen
> * The earlier series to fix how sections are represented in symbols
> removes the need for the old "index" patches
>
> I built and regtested this on x86-64 Fedora 18 (with the defaults and
> with -gstabs+), PPC Linux (gcc110 in the compile farm), and AIX
> (gcc111 in the compile farm). I also built it on Fedora 18 using the
> mingw cross compiler.
>
>
> Please note that, while I made my best effort to fix everything
> properly, there's really quite a bit here I can't test. In
> particular, I have no way to test most of the changes I made to the
> various symbol readers, in patch #8.
>
> If you could, I'd ask that you please test or at least carefully
> review the relevant bits there. I've pushed this branch to archer.git
> tromey/split-objfile/msymbol-location-independence to make this
> simpler.
There are no new test failures on this branch for arm-linux.
--
Will Newton
Toolchain Working Group, Linaro
next prev parent reply other threads:[~2013-10-18 10:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 17:50 Tom Tromey
2013-10-17 17:50 ` [PATCH v2 4/9] use bound_minsym as result for lookup_minimal_symbol et al Tom Tromey
2013-10-17 17:50 ` [PATCH v2 2/9] change minsym representation Tom Tromey
2013-10-17 17:50 ` [PATCH v2 5/9] start change to progspace independence Tom Tromey
2013-10-17 17:50 ` [PATCH v2 1/9] introduce minimal_symbol_upper_bound Tom Tromey
2013-10-18 22:01 ` Doug Evans
2013-10-21 16:23 ` Tom Tromey
2013-10-21 16:47 ` Doug Evans
2013-10-17 17:50 ` [PATCH v2 9/9] add short-circuit logic to elfread.c Tom Tromey
2013-10-18 22:46 ` Doug Evans
2013-10-20 19:53 ` Tom Tromey
2013-10-21 16:44 ` Doug Evans
2013-10-21 18:50 ` Tom Tromey
2013-10-21 19:52 ` Doug Evans
2013-10-29 18:31 ` Tom Tromey
2013-10-17 17:50 ` [PATCH v2 3/9] make MSYMBOL_VALUE_ADDRESS an rvalue Tom Tromey
2013-10-17 17:50 ` [PATCH v2 7/9] move minimal symbols to per-bfd Tom Tromey
2013-10-17 17:50 ` [PATCH v2 8/9] split out elf_read_minimal_symbols Tom Tromey
2013-10-17 18:34 ` [PATCH v2 6/9] change minsyms not to be relocated at read-time Tom Tromey
2013-10-18 10:32 ` Will Newton [this message]
2013-10-18 18:35 ` [PATCH v2 0/9] share minimal symbols across objfiles Tom Tromey
2014-01-13 20:59 ` Tom Tromey
2014-02-26 18:48 ` Pedro Alves
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='CANu=DmjOE3GNh25k85pK72wBG7+2xwcF-V5LJhHYQHk-Hdr1vA@mail.gmail.com' \
--to=will.newton@linaro.org \
--cc=gdb-patches@sourceware.org \
--cc=tromey@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).