This is the mail archive of the
mailing list for the GCC project.
Re: Move unwind info to read-only section on AIX
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Andrew Dixie <andrewdixie50 at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 30 Jul 2014 22:22:51 -0400
- Subject: Re: Move unwind info to read-only section on AIX
- Authentication-results: sourceware.org; auth=none
- References: <CAPrih1nqm8w0YoCdBv6iuj_56JmvXGSGQFh5rwa3GS3sLrf5hQ at mail dot gmail dot com>
On Tue, Jul 29, 2014 at 5:33 PM, Andrew Dixie <firstname.lastname@example.org> wrote:
> The following patch moves dwarf unwind information from the data
> section to the read-only/text section on AIX. This means the memory
> for the unwind information can be shared across multiple processes.
> The frame tables are still registered through collect2 scanning for
> "_GLOBAL_F" symbol names, however these symbols now exist in the
> eh_frame section.
> Previously all the unwind pointers were absolute (requiring
> relocations), these have been changed to PC-relative and data-relative
> The DW_EH_PE_datarel encoding doesn't appear to have previously been
> used in the compiler, but it is already implemented in the runtime
> unwind code.
> The data relative encoding is needed as a PC relative offset cannot
> point from the text section to the data section on AIX.
> For the base for the data relative offset, I couldn't find any way to
> get a reference to the start of the data segment, so this patch uses
> the symbol __dso_handle as an arbitrary base for the data relative
> I'm considering changing the base to be the TOC.
> I'm Interested in thoughts or ideas on a better base for the data
> relative offsets?
Thanks for working on this.
As the comment in the code states DWARF2 unwind info was placed in the
data section to prevent the AIX linker from garbage collecting it.
How are you avoiding that problem?
Also, the AIX linker uses "$" for the current location, so the kludge
of creating PCREL symbols should not be necessary.
Using __dso_handle as the base address is underwhelming.