This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> On Mon, 8 Dec 2003 17:08:44 +0100, Jakub Jelinek <jakub@redhat.com> said: Jakub> The current IA-64 AT_SYSINFO_EHDR virtual DSO seems to be Jakub> unfortunately binary incompatible with older GCCs, which is Jakub> IMHO a bad thing. When kernel provides AT_SYSINFO_EHDR but Jakub> userland doesn't grok it yet, things should work the old way. Jakub> I think simply swapping the 2 PT_LOAD segments in virtual DSO Jakub> would help, ie. put PF_E segment before PF_R. Jakub> AT_SYSINFO_EHDR would point to the Elf64_Ehdr (followed by Jakub> Elf64_Phdrs) in the PF_R, ie. 0xa000000000020000. One possitiblity would be for glibc NOT to register the AT_SYSINFO_EHDR on ia64 for now (i.e., dl_iterate_phdr() wouldn't find the kernel DSO). libunwind will then fall back on using the getunwind() system call. Not pretty, but it would be backwards compatible. Of course, longer term, we'd want to get rid of this workaround. The question is whether there could be a quick and reliable test to discover whether the unwinder can handle .unwabi. Unfortunately this is complicatd by the fact that we may be dealing with multiple unwinders (statically linked in and one loaded dynamically via libgcc_s). --david
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |