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]

Re: new syscall stub support for ia64 libc


On Mon, Dec 08, 2003 at 11:09:59AM -0800, David Mosberger wrote:
> >>>>> 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.

It will not.  The thing is that MD_FALLBACK_FRAME_STATE_FOR special handles
the signal trampoline only if it is between:

#define IA64_GATE_AREA_START 0xa000000000000100LL
#define IA64_GATE_AREA_END   0xa000000000020000LL

#define MD_FALLBACK_FRAME_STATE_FOR(CONTEXT, FS, SUCCESS)               \
  if ((CONTEXT)->rp >= IA64_GATE_AREA_START                             \
      && (CONTEXT)->rp < IA64_GATE_AREA_END)                            \
    {                                                                   \
...

(that's still in current GCC).
If ld.so is not aware about AT_SYSINFO_EHDR, then
MD_FALLBACK_FRAME_STATE_FOR is where the signal trampoline should be
handled.
In 2.4.x kernels the signal trampoline indeed lived between
0xa000000000010000 and 0xa000000000020000, but with the VDSO changes
it now is at 0xa0000000000207e0 though.
That's why I've suggested to swap the 2 segments, then the signal
trampoline would be at 0xa0000000000107e0 and unmodified libgcc_s.so.1
would keep working (as long as ld.so has not included AT_SYSINFO_EHDR).

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]