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]

__libc_stack_end and friends on IA64


I'm forwarding this for Hans Boehm.

	--david

--- Begin Message ---
David -

Could you forward this to libc-hackers, unless Jes or Ulrich wants to
volunteer to fix it?  I don't have a current glibc tree.

Currently the libc startup code attempts to set __libc_stack_end to the
stack base (all platforms) and __libc_ia64_register_backing_store_base to
the register stack base (ia64 only).  On ia64, the correct values are in
fact set once main is started, but both values are wrong, for different
reasons, while initialization code is running.

The problems are that the RTLD_START macro in sysdeps/ia64/dl-machine.h:

1) Doesn't set __libc_ia64_register_backing_store_base at all.  This means
that it's zero while initialization code is running.

2) Sets __libc_stack_end to the sp value.  This is incorect, since it
excludes the scratch area just above the sp.  It should be set to sp+16, as
it is for the main program.

The first problem forces our garbage collector to understand the kernel rule
for placing the backing store (which it currently does as a fallback).

The second one implies that __libc_stack_end in fact changes slightly
between the initialization code and the main program.  For at least one test
program, an interesting C++ data structure ended up in the region which was
initially excluded.  That then caused our garbage collector to fail.  (I can
work around that for now, but the glibc bug should also be fixed.)

Hans
--- End Message ---

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