This is the mail archive of the
mailing list for the GCC project.
Re: Does your .eh_frame_hdr change work with DW_EH_PE_absptr?
On Thu, Feb 14, 2002 at 09:02:39AM +0100, Jakub Jelinek wrote:
> On Wed, Feb 13, 2002 at 04:43:39PM -0800, H . J . Lu wrote:
> > "make check" in gcc has many C++ exception failures on Linux/mips with
> > the current gcc/binutils. I noticed that Linux/mips uses the default
> > ASM_PREFERRED_EH_DATA_FORMAT, which is DW_EH_PE_absptr. Does your
> > change work with DW_EH_PE_absptr?
> It wouldn't work on IA-32 either if absptr did not work - all non-pic code
> uses there absptr.
> Can you cook up a minimal testcase which triggers it (the fewer FDEs and
> CIEs the better) and mail me the resulting .so or binary for inspection for
> now (I might need all the source objects/libs for the final link later to
> debug it, but for inspection the final link result should be enough)?
I think I found the problem. The content of the .eh_frame_hdr section,
especially the initial location field in FDE, is wrong for MIPS in a
shared library. The value recorded is the one before the adjustment
is made by ld.so. In mips32-elf.c:
|| (elf_hash_table (info)->dynamic_sections_created
&& h != NULL
& ELF_LINK_HASH_DEF_DYNAMIC) != 0)
& ELF_LINK_HASH_DEF_REGULAR) == 0)))
&& r_symndx != 0
&& (input_section->flags & SEC_ALLOC) != 0)
/* If we're creating a shared library, or this relocation is
against a symbol in a shared library, then we can't know
where the symbol will end up. So, we create a relocation
record in the output, and leave the job up to the dynamic
value = addend;
if (!mips_elf_create_dynamic_relocation (abfd,
I don't know what the best way to fix it is. Given the problem I see
on Linux/mips, I don't know how well your scheme will work on other
platforms. The key is you have to make sure the .eh_frame_hdr section
needs no run-time relocation or provide the relocation records for it.
I believe you should require the .eh_frame_hdr section needs no