Prev: error
Next: Automake Conditional and ARG_VAR Question
From: boltar2003 on 28 Apr 2010 08:39
On Wed, 28 Apr 2010 13:47:12 +0200
Noob <root(a)127.0.0.1> wrote:
>Nicolas George wrote:
>
>> Noob wrote:
>>
>>> .text
>>> .globl _get_current_stack_pointer
>>> _get_current_stack_pointer:
>>> movl %esp, %eax
>>> ret
>>
>> void *get_approx_stack_pointer(void)
>> {
>> int a;
>> return(&a);
>> }
>
>3.1.2.4 Storage durations of objects
>
>The value of a pointer that referred to an object with automatic storage
>duration that is no longer guaranteed to be reserved is indeterminate.

Unless the compiler was really smart you could probably just fool it
by doing:

int a;
char *ptr;
ptr = &a;
return ptr;

B2003

From: Scott Lurndal on 28 Apr 2010 11:21
boltar2003(a)boltar.world writes:
>On Wed, 28 Apr 2010 02:31:06 +0200
>Sjouke Burry <burrynulnulfour(a)ppllaanneett.nnll> wrote:
>>> Are you sure that the problem is the stack limit and not another form
>>> of memory corruption? What does the debugger tell you?
>>Last time I had a stack problem, I just wrote a very small
>>assembler routine, to return the value of the stackpointer.
>>That value, as the stack became full , moved to zero.
>>So if your system works likewise, use such a routine to
>>quit at the right moment, while there is still some left.
>
>Is there a way of doing that in C rather than assembler? My x86 assembler
>isn't great but I want the program to be portable anyway.
>
>B2003
>
This works for GCC 64-bit (but in your case, you're likely seeing heap corruption,
not a stack overflow - note that you can adjust the max size of the stack through the
ulimit bash/ksh builtin command.)

Substitute 'movl' for 'movq' and '%%esp'/'%%ebp' for '%%rsp'/'%%ebp' in 32-bit.

#define ALWAYS_INLINE inline __attribute__((always_inline))

static ALWAYS_INLINE uintptr_t
get_rsp()
{
uintptr_t rsp;

__asm__ __volatile__ ("movq %%rsp, %0": "=r" (rsp));

return rsp;
}

static ALWAYS_INLINE uintptr_t
get_rbp()
{
uintptr_t rbp;

__asm__ __volatile__ ("movq %%rbp, %0": "=r" (rbp));
return rbp;
}
From: James Kanze on 28 Apr 2010 14:46
On Apr 28, 10:56 am, Öö Tiib <oot...(a)hot.ee> wrote:
> On Apr 28, 12:17 pm, boltar2...(a)boltar.world wrote:

> > On Wed, 28 Apr 2010 02:31:06 +0200

> > Sjouke Burry <burrynulnulf...(a)ppllaanneett.nnll> wrote:
> > >> Are you sure that the problem is the stack limit and not
> > >> another form of memory corruption? What does the debugger
> > >> tell you?
> > >Last time I had a stack problem, I just wrote a very small
> > >assembler routine, to return the value of the stackpointer.
> > >That value, as the stack became full , moved to zero. So
> > >if your system works likewise, use such a routine to quit
> > >at the right moment, while there is still some left.

> > Is there a way of doing that in C rather than assembler? My
> > x86 assembler isn't great but I want the program to be
> > portable anyway.

> There are no way to do it in C because stack and its location,
> size and direction are platform specific. There may be
> platform specific libraries that have functions to do
> something in C. If there are none then you may have to write
> it (or parts of it) in assember.

It's normally no problem to get the address of the stack in C or
C++; just take the address of a local variable. (This isn't
guaranteed by the standard, of course, which doesn't even
guarantee that there is a stack, per se.) What that address
means, and what information you can deduce from it, is very
implementation specific, but for a given platform, you can often
determine something. (I've written stack walkback routines for
a number of platforms in C++. The code for one platform doesn't
work on other platforms, but it's still C++.)

> If you have implementation that should be portable and that
> depends on properties of stack then you end up having that
> functionality differently implemented for each plaform used.
> So you should perhaps enwrap it behind common interface to
> keep your code readable.

Yes. This is the usual solution.

--
James Kanze

From: Scott Lurndal on 28 Apr 2010 15:20
James Kanze <james.kanze(a)gmail.com> writes:
>On Apr 28, 10:56 am, =D6=F6 Tiib <oot...(a)hot.ee> wrote:
>> On Apr 28, 12:17 pm, boltar2...(a)boltar.world wrote:
>
>> > On Wed, 28 Apr 2010 02:31:06 +0200
>
>> > Sjouke Burry <burrynulnulf...(a)ppllaanneett.nnll> wrote:
>> > >> Are you sure that the problem is the stack limit and not
>> > >> another form of memory corruption? What does the debugger
>> > >> tell you?
>> > >Last time I had a stack problem, I just wrote a very small
>> > >assembler routine, to return the value of the stackpointer.
>> > >That value, as the stack became full , moved to zero. So
>> > >if your system works likewise, use such a routine to quit
>> > >at the right moment, while there is still some left.
>
>> > Is there a way of doing that in C rather than assembler? My
>> > x86 assembler isn't great but I want the program to be
>> > portable anyway.
>
>> There are no way to do it in C because stack and its location,
>> size and direction are platform specific. There may be
>> platform specific libraries that have functions to do
>> something in C. If there are none then you may have to write
>> it (or parts of it) in assember.
>
>It's normally no problem to get the address of the stack in C or
>C++; just take the address of a local variable. (This isn't
>guaranteed by the standard, of course, which doesn't even
>guarantee that there is a stack, per se.) What that address
>means, and what information you can deduce from it, is very
>implementation specific, but for a given platform, you can often
>determine something. (I've written stack walkback routines for
>a number of platforms in C++. The code for one platform doesn't
>work on other platforms, but it's still C++.)

GCC/G++/GLIBC has this built-in now:

#include <execinfo.h>

/**
* Log a simulator stack traceback.
*/
void
c_system::backtrace(void)
{
int num_frames;
void *framelist[100];
char **strings;

num_frames = ::backtrace(framelist, sizeof(framelist)/sizeof(framelist[0]));
strings = ::backtrace_symbols(framelist, num_frames);
if (strings == NULL) {
log("Unable to obtain stack simulator stack traceback: %s\n",
strerror(errno));
return;
}
for(int frame=0; frame < num_frames; frame++) {
log("[%2.2d] %s\n", frame, strings[frame]);
}
::free(strings);
}

scott
From: Ben Bacarisse on 29 Apr 2010 09:13
Noob <root(a)127.0.0.1> writes:

> Nicolas George wrote:
>
>> Noob wrote:
>>
>>> .text
>>> .globl _get_current_stack_pointer
>>> _get_current_stack_pointer:
>>> movl %esp, %eax
>>> ret
>>
>> void *get_approx_stack_pointer(void)
>> {
>> int a;
>> return(&a);
>> }
>
> 3.1.2.4 Storage durations of objects
>
> The value of a pointer that referred to an object with automatic storage
> duration that is no longer guaranteed to be reserved is indeterminate.
>
> AFAIU, a conforming compiler is free to change the function to
>
> void *get_approx_stack_pointer(void)
> {
> return NULL;
> }
>
> However, gcc 4.3.2 does not perform this optimization.

I'd write:

uintptr_t get_approx_stack_pointer(void)
{
int a;
return (uintptr_t)&a;
}

to avoid this problem (#include <stdint.h> of course).

<snip>
--
Ben.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: error
Next: Automake Conditional and ARG_VAR Question