This is the mail archive of the mailing list for the glibc project.

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: [PATCH 2/2][BZ #12416] Use stack boundaries from /proc/PID/mapsto make stack executable

On Mon, 14 May 2012 16:46:22 -0700 (PDT), Roland wrote:
> I don't think it's reliable to use __builtin_frame_address with a
> nonzero argument, depending on optimization behavior and such.
> Why don't you just use #if _STACK_GROWS_{DOWN,UP} here?

The macro is defined only within the glibc sources in stackinfo.h. I
reckoned that test cases should be using only publicly available
interfaces within glibc, which is why I wrote this instead. Is it OK
to use stackinfo.h here?
> This says we're not checking them separately but doesn't really say
> why, or at least not clearly enough for me.  If it's really the case
> that the two could change such that their sum/difference remains the
> same and that would be kosher, then explain it more thoroughly.  If
> not, then just check them separately.

It is possible that the dlopen'd module may have been mmapped just
above the stack. The stack size is taken as MIN(stack rlimit size, end
of last vma) in pthread_getattr_np, so it is possible that the size
may have changed as a result if the rlimit is set high enough.

A subsequent call to pthread_attr_getstack returns the size and
(bottom - size) as the stacksize and stackaddr respectively. Due to the
above it is clear that if size changes due to the new mapping, then both
stacksize and stackaddr can change, but the stack bottom should remain
the same, which is nothing but stackaddr + stacksize.


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