On Thu, 23 Nov 2006, Jan Stary wrote:
[snip]
> >
> > 2153 foo CALL munmap(0x470d7000,0x1000)
> > 2153 foo RET munmap 0
> > 2153 foo CALL exit(0)
> > $
>
> thanks! This exactly is the minimal example I wanted to understand.
> Would you please recommend a piece of literat
Hi,
> $ cat > foo.c
> int main() { return 0; }
> $ cc -static -o foo foo.c
> $ ktrace ./foo
> $ kdump
> 2153 ktrace RET ktrace 0
> 2153 ktrace CALL execve(0x7f7f910f,0x7f7f8c78,0x7f7f8c88)
> 2153 ktrace NAMI "./foo"
> 2153 foo EMUL "native"
> 2153 foo RET
On 22 Nov 2006 09:52:09 +0100, Artur Grabowski <[EMAIL PROTECTED]> wrote:
...
There are two problems with this. One is that memory is protected from
writing, that's why there are those calls to mprotect all over the
place. The other problem is that dynamic binding isn't reentrant, we
don't want s
"Olivier Meyer" <[EMAIL PROTECTED]> writes:
> Most of what you see is the libc setting up default signal stuff.
> After the ELF is loaded mprotect is used to make the area executable,
> so when EIP is set to the starting point, the program does not SEGV.
Erm. No. Sorry, not correct at all. Wouldn
On Tue, 21 Nov 2006, Olivier Meyer wrote:
> Most of what you see is the libc setting up default signal stuff.
> After the ELF is loaded mprotect is used to make the area executable,
> so when EIP is set to the starting point, the program does not SEGV.
>
> As to understanding, I would read the ap
On Tue, Nov 21, 2006 at 06:46:49PM -0700, Olivier Meyer wrote:
> Most of what you see is the libc setting up default signal stuff.
> After the ELF is loaded mprotect is used to make the area executable,
> so when EIP is set to the starting point, the program does not SEGV.
>
> As to understanding,
Most of what you see is the libc setting up default signal stuff.
After the ELF is loaded mprotect is used to make the area executable,
so when EIP is set to the starting point, the program does not SEGV.
As to understanding, I would read the appropriate code in the kernel.
On 11/21/06, Jan Star
7 matches
Mail list logo
