Getting information on stack usage?

Hi,

It seems that we’re hitting the stack limit for threads in our application.

Since we’re plugging in to a framework (actually, a driver module for
io-net), we do not have control over the stack size allocated to us.

In order to reduce our stack usage, we need to know where we’re “too deep” -
currently this is a problem, because when we crash, the stack is hosed, and
we have no traceback.

I was wondering if there’s a tool or method for tracking the stack usage of
a running thread/process? Ideally, I’d like to say something like “break
when stack_free < 100 bytes”.

A special-purpose tool, code framework or gdb magic would all be fine.

Any ideas?

Thanks,

Rony

Rony Shapiro <rshapiro@maya-st.com> wrote:

Hi,

It seems that we’re hitting the stack limit for threads in our application.

Since we’re plugging in to a framework (actually, a driver module for
io-net), we do not have control over the stack size allocated to us.

You can, however, malloc() a block of memory, and using pthread_attr_*()
to initilize a pthread_attr, and call pthread_create().

Thus your new created thread will have it’s own stackaddr, and size.

In order to reduce our stack usage, we need to know where we’re “too deep” -
currently this is a problem, because when we crash, the stack is hosed, and
we have no traceback.

I was wondering if there’s a tool or method for tracking the stack usage of
a running thread/process? Ideally, I’d like to say something like “break
when stack_free < 100 bytes”.

A special-purpose tool, code framework or gdb magic would all be fine.

For runtime check, look into (I assume this is x86):

http://cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c/support/x86/__stackavail.c

If you break into gdb, just info reg, and check the esp against your
stack addr (since you allocated it, you know the address).

-xtang

Xiaodan Tang <xtang@qnx.com> wrote:
: Rony Shapiro <rshapiro@maya-st.com> wrote:
:> Hi,

:> It seems that we’re hitting the stack limit for threads in our application.

:> Since we’re plugging in to a framework (actually, a driver module for
:> io-net), we do not have control over the stack size allocated to us.

: You can, however, malloc() a block of memory, and using pthread_attr_*()
: to initilize a pthread_attr, and call pthread_create().

: Thus your new created thread will have it’s own stackaddr, and size.

I think he’s being called from npm-tcpip.so and is therefor using it’s
stack.

:> In order to reduce our stack usage, we need to know where we’re “too deep” -
:> currently this is a problem, because when we crash, the stack is hosed, and
:> we have no traceback.

:> I was wondering if there’s a tool or method for tracking the stack usage of
:> a running thread/process? Ideally, I’d like to say something like “break
:> when stack_free < 100 bytes”.

:> A special-purpose tool, code framework or gdb magic would all be fine.

: For runtime check, look into (I assume this is x86):

: http://cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c/support/x86/__stackavail.c

__stackavail() won’t give meaningful results with the 6.1 npm-tcpip.so.
This is fixed in 6.2.

: If you break into gdb, just info reg, and check the esp against your
: stack addr (since you allocated it, you know the address).

or in gdb just do a:
(gdb) call __stackavail()

But again, this won’t give meaningful results if you’re called from the
6.1 npm-tcpip.so.

-seanb

Sean, Xiaodan,

Indeed, this is a continuation of the thread I started in the ddk.nrtwork
newsgroup (pun unintended).

  • the call is indeed from npm-tcpip.so (or so I assume - the problem is in
    the context of tcp/ip traffic going between an Ethernet card and a serial
    line (over PPP), with us in the middle as an ip-ip intermediate driver.
  • I assume that starting our own thread wouldn’t make sense…
  • The target platform is the PPC RPX-Lite, FWIW, although we also have QNX
    on x86 for development.

If I understand you correctly, there’s no effective way to “clean up” our
stack usage, since we can’t find the bottleneck :frowning:

(This is all on QNX 6.1A, BTW)

Thanks,

Rony

“Sean Boudreau” <seanb@qnx.com> wrote in message
news:a3c3ul$rbv$1@nntp.qnx.com

Xiaodan Tang <> xtang@qnx.com> > wrote:
: Rony Shapiro <> rshapiro@maya-st.com> > wrote:
:> Hi,

:> It seems that we’re hitting the stack limit for threads in our
application.

:> Since we’re plugging in to a framework (actually, a driver module for
:> io-net), we do not have control over the stack size allocated to us.

: You can, however, malloc() a block of memory, and using pthread_attr_*()
: to initilize a pthread_attr, and call pthread_create().

: Thus your new created thread will have it’s own stackaddr, and size.

I think he’s being called from npm-tcpip.so and is therefor using it’s
stack.

:> In order to reduce our stack usage, we need to know where we’re “too
deep” -
:> currently this is a problem, because when we crash, the stack is hosed,
and
:> we have no traceback.

:> I was wondering if there’s a tool or method for tracking the stack
usage of
:> a running thread/process? Ideally, I’d like to say something like
“break
:> when stack_free < 100 bytes”.

:> A special-purpose tool, code framework or gdb magic would all be fine.

: For runtime check, look into (I assume this is x86):

: > http://cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c/support/x86/__stackavail.c

__stackavail() won’t give meaningful results with the 6.1 npm-tcpip.so.
This is fixed in 6.2.

: If you break into gdb, just info reg, and check the esp against your
: stack addr (since you allocated it, you know the address).

or in gdb just do a:
(gdb) call __stackavail()

But again, this won’t give meaningful results if you’re called from the
6.1 npm-tcpip.so.

-seanb

Rony Shapiro <rshapiro@maya-st.com> wrote:
: Sean, Xiaodan,

: Indeed, this is a continuation of the thread I started in the ddk.nrtwork
: newsgroup (pun unintended).

: - the call is indeed from npm-tcpip.so (or so I assume - the problem is in
: the context of tcp/ip traffic going between an Ethernet card and a serial
: line (over PPP), with us in the middle as an ip-ip intermediate driver.
: - I assume that starting our own thread wouldn’t make sense…
: - The target platform is the PPC RPX-Lite, FWIW, although we also have QNX
: on x86 for development.

: If I understand you correctly, there’s no effective way to “clean up” our
: stack usage, since we can’t find the bottleneck :frowning:

Not really, other than by trial and error. It’s definitely more difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work in this
area since 6.1. Don’t discount libc functions. Some of them have been found
to be stack hungy as part of the above exercise.

-seanb

: (This is all on QNX 6.1A, BTW)

: Thanks,

: Rony

: “Sean Boudreau” <seanb@qnx.com> wrote in message
: news:a3c3ul$rbv$1@nntp.qnx.com
:> Xiaodan Tang <xtang@qnx.com> wrote:
:> : Rony Shapiro <rshapiro@maya-st.com> wrote:
:> :> Hi,
:>
:> :> It seems that we’re hitting the stack limit for threads in our
: application.
:>
:> :> Since we’re plugging in to a framework (actually, a driver module for
:> :> io-net), we do not have control over the stack size allocated to us.
:>
:> : You can, however, malloc() a block of memory, and using pthread_attr_*()
:> : to initilize a pthread_attr, and call pthread_create().
:>
:> : Thus your new created thread will have it’s own stackaddr, and size.
:>
:> I think he’s being called from npm-tcpip.so and is therefor using it’s
:> stack.
:>
:> :> In order to reduce our stack usage, we need to know where we’re “too
: deep” -
:> :> currently this is a problem, because when we crash, the stack is hosed,
: and
:> :> we have no traceback.
:>
:> :> I was wondering if there’s a tool or method for tracking the stack
: usage of
:> :> a running thread/process? Ideally, I’d like to say something like
: “break
:> :> when stack_free < 100 bytes”.
:>
:> :> A special-purpose tool, code framework or gdb magic would all be fine.
:>
:> : For runtime check, look into (I assume this is x86):
:>
:> : http://cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c/support/x86/__stackavail.c
:>
:> __stackavail() won’t give meaningful results with the 6.1 npm-tcpip.so.
:> This is fixed in 6.2.
:>
:> : If you break into gdb, just info reg, and check the esp against your
:> : stack addr (since you allocated it, you know the address).
:>
:> or in gdb just do a:
:> (gdb) call __stackavail()
:>
:> But again, this won’t give meaningful results if you’re called from the
:> 6.1 npm-tcpip.so.
:>
:> -seanb

Hi Sean,

I was afraid that would be the situation. Perhaps a list of the “stack
hungry” libc functions would help? We might start by grepping for them in
our code…

Thanks,

Rony

“Sean Boudreau” <seanb@qnx.com> wrote in message
news:a3e981$ff6$2@nntp.qnx.com

Rony Shapiro <> rshapiro@maya-st.com> > wrote:
: Sean, Xiaodan,

: Indeed, this is a continuation of the thread I started in the
ddk.nrtwork
: newsgroup (pun unintended).

[…]
: If I understand you correctly, there’s no effective way to “clean up”
our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work in
this
area since 6.1. Don’t discount libc functions. Some of them have been
found
to be stack hungy as part of the above exercise.

-seanb

Hi again,

Another thought just struck me - would it be possible to create and run a
profiling version of our module under io-net? Perhaps this would provide the
information about our calling trees?

Rony

“Sean Boudreau” <seanb@qnx.com> wrote in message
news:a3e981$ff6$2@nntp.qnx.com

Rony Shapiro <> rshapiro@maya-st.com> > wrote:
: Sean, Xiaodan,

: Indeed, this is a continuation of the thread I started in the
ddk.nrtwork
: newsgroup (pun unintended).

: - the call is indeed from npm-tcpip.so (or so I assume - the problem is
in
: the context of tcp/ip traffic going between an Ethernet card and a
serial
: line (over PPP), with us in the middle as an ip-ip intermediate driver.
: - I assume that starting our own thread wouldn’t make sense…
: - The target platform is the PPC RPX-Lite, FWIW, although we also have
QNX
: on x86 for development.

: If I understand you correctly, there’s no effective way to “clean up”
our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work in
this
area since 6.1. Don’t discount libc functions. Some of them have been
found
to be stack hungy as part of the above exercise.

-seanb

: (This is all on QNX 6.1A, BTW)

: Thanks,

: Rony

: “Sean Boudreau” <> seanb@qnx.com> > wrote in message
: news:a3c3ul$rbv$> 1@nntp.qnx.com> …
:> Xiaodan Tang <> xtang@qnx.com> > wrote:
:> : Rony Shapiro <> rshapiro@maya-st.com> > wrote:
:> :> Hi,
:
:> :> It seems that we’re hitting the stack limit for threads in our
: application.
:
:> :> Since we’re plugging in to a framework (actually, a driver module
for
:> :> io-net), we do not have control over the stack size allocated to us.
:
:> : You can, however, malloc() a block of memory, and using
pthread_attr_*()
:> : to initilize a pthread_attr, and call pthread_create().
:
:> : Thus your new created thread will have it’s own stackaddr, and size.
:
:> I think he’s being called from npm-tcpip.so and is therefor using it’s
:> stack.
:
:> :> In order to reduce our stack usage, we need to know where we’re “too
: deep” -
:> :> currently this is a problem, because when we crash, the stack is
hosed,
: and
:> :> we have no traceback.
:
:> :> I was wondering if there’s a tool or method for tracking the stack
: usage of
:> :> a running thread/process? Ideally, I’d like to say something like
: “break
:> :> when stack_free < 100 bytes”.
:
:> :> A special-purpose tool, code framework or gdb magic would all be
fine.
:
:> : For runtime check, look into (I assume this is x86):
:
:> :
http://cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/c/support/x86/__stackavail.c
:
:> __stackavail() won’t give meaningful results with the 6.1 npm-tcpip.so.
:> This is fixed in 6.2.
:
:> : If you break into gdb, just info reg, and check the esp against your
:> : stack addr (since you allocated it, you know the address).
:
:> or in gdb just do a:
:> (gdb) call __stackavail()
:
:> But again, this won’t give meaningful results if you’re called from the
:> 6.1 npm-tcpip.so.
:
:> -seanb

Sean Boudreau <seanb@qnx.com> wrote:

Rony Shapiro <> rshapiro@maya-st.com> > wrote:
: Sean, Xiaodan,

: Indeed, this is a continuation of the thread I started in the ddk.nrtwork
: newsgroup (pun unintended).

: - the call is indeed from npm-tcpip.so (or so I assume - the problem is in
: the context of tcp/ip traffic going between an Ethernet card and a serial
: line (over PPP), with us in the middle as an ip-ip intermediate driver.
: - I assume that starting our own thread wouldn’t make sense…
: - The target platform is the PPC RPX-Lite, FWIW, although we also have QNX
: on x86 for development.

: If I understand you correctly, there’s no effective way to “clean up” our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work in this
area since 6.1. Don’t discount libc functions. Some of them have been found
to be stack hungy as part of the above exercise.

Well, I can think of some “sneak way” of changing stack “on the fly”.
If you playing with setjmp()/longjmp() correct.

Basically before calling a function in question, you setjmp(), store
the orignal sp, feed your own allocated memory to sp, and long jmp
to it.

After returning from the function, setjmp(), restore orignal sp, longjmp()
to resume oringal stack.

-xtang

Hi Xiaodan!

I think that “sneaky” is definitely in order at this stage!

Can you give me a code snippet showing what you meant. I get the general
idea, but I’m not sure, for example, how to manipulate the sp in the manner
you describe.

Also, this has to be both for x86 (for development/testing) and for PowerPC
(production).

Thanks,

Rony
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:a3ee4o$inp$1@nntp.qnx.com
[…]

: If I understand you correctly, there’s no effective way to “clean up”
our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more
difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work in
this
area since 6.1. Don’t discount libc functions. Some of them have been
found
to be stack hungy as part of the above exercise.

Well, I can think of some “sneak way” of changing stack “on the fly”.
If you playing with setjmp()/longjmp() correct.

Basically before calling a function in question, you setjmp(), store
the orignal sp, feed your own allocated memory to sp, and long jmp
to it.

After returning from the function, setjmp(), restore orignal sp, longjmp()
to resume oringal stack.

-xtang

Rony Shapiro <rshapiro@maya-st.com> wrote:

Hi Xiaodan!
I think that “sneaky” is definitely in order at this stage!
Can you give me a code snippet showing what you meant. I get the general
idea, but I’m not sure, for example, how to manipulate the sp in the manner
you describe.

Also, this has to be both for x86 (for development/testing) and for PowerPC
(production).

I don’t have document in hand, but here is what in my mind:

char * mystack = malloc(mystacksize);
jmp_buf env;
void *stored_sp;
char *esp;

/* before call into a function /
if (setjmp(&env) == 0) {
/
this part is different between PPC and X86

  • check ansi/$(CPU)/_jmp.S
    */
    esp = (char *)env + 0x2c;

stored_sp = *(int *)esp;
*(int *)esp = mystack + mystacksize - sizeof(int);
longjmp(&env);
}

MyFunctionNeedBigStack();

/* after the call, restore orignal esp */
if (setjmp(&env) == 0) {
esp = (char *)env + 0x2c;
*(int *)esp = stored_sp;
longjmp(&env);
}

For libc source, check cvs.qnx.com.

-xtang

Thanks,

Rony
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:a3ee4o$inp$> 1@nntp.qnx.com> …
[…]
: If I understand you correctly, there’s no effective way to “clean up”
our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more
difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work in
this
area since 6.1. Don’t discount libc functions. Some of them have been
found
to be stack hungy as part of the above exercise.

Well, I can think of some “sneak way” of changing stack “on the fly”.
If you playing with setjmp()/longjmp() correct.

Basically before calling a function in question, you setjmp(), store
the orignal sp, feed your own allocated memory to sp, and long jmp
to it.

After returning from the function, setjmp(), restore orignal sp, longjmp()
to resume oringal stack.

-xtang

Good morning Xiaodan,

Thanks for the code snippet - lovely hack, in the true sense of the word!

However, it looks like we may have a problem using it in our context (pun
unintended):

We have verified that io-net crashes, apparently due to running out of
stack, in the following setup:

  1. “Big” TCP/IP stack (npm-tcpip.so)
  2. Tunneling via PPP (npm-pppmgr.so)
  3. A certain traffic pattern, consisting of several short (~40 byte) TCP
    packets going across in rapid succession
  4. Any intermediate (“ip”-“ip”) filter loaded into io-net that handles the
    packets.
  • Remove any one of the above conditions, and everything works fine.
  • About “any” in item 4: we have replaced our filter with a “null” filter
    that basically passes the packets up and down the network stack - the crash
    still occurs. (This make your suggestion moot, since we no longer have a
    MyFunctionNeedBigStack() to wrap…)

I tried to cross-post this to qdn.public.ddk.network, since this pertains to
the
“just passing packets → npm-tcpip.so crash” thread I’ve started there, but
the NNTP server apparently dislikes cross-posts…

Also, attached please find the null shim that we’ve used to verify the
problem - perhaps we’re doing somethng inherently silly?

Any solution within the 6.1A framework would be wonderful!

Thanks,

Rony

p.s. - I can also send Java executables for server/client apps that
reproduce the fatal traffic pattern.

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:a3l28k$d2m$1@nntp.qnx.com

Rony Shapiro <> rshapiro@maya-st.com> > wrote:

Hi Xiaodan!
I think that “sneaky” is definitely in order at this stage!
Can you give me a code snippet showing what you meant. I get the general
idea, but I’m not sure, for example, how to manipulate the sp in the
manner
you describe.

Also, this has to be both for x86 (for development/testing) and for
PowerPC
(production).

I don’t have document in hand, but here is what in my mind:

char * mystack = malloc(mystacksize);
jmp_buf env;
void *stored_sp;
char *esp;

/* before call into a function /
if (setjmp(&env) == 0) {
/
this part is different between PPC and X86

  • check ansi/$(CPU)/_jmp.S
    */
    esp = (char *)env + 0x2c;

stored_sp = *(int *)esp;
*(int *)esp = mystack + mystacksize - sizeof(int);
longjmp(&env);
}

MyFunctionNeedBigStack();

/* after the call, restore orignal esp */
if (setjmp(&env) == 0) {
esp = (char *)env + 0x2c;
*(int *)esp = stored_sp;
longjmp(&env);
}

For libc source, check cvs.qnx.com.

-xtang

Thanks,

Rony
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:a3ee4o$inp$> 1@nntp.qnx.com> …
[…]
: If I understand you correctly, there’s no effective way to “clean
up”
our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more
difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work
in
this
area since 6.1. Don’t discount libc functions. Some of them have
been
found
to be stack hungy as part of the above exercise.

Well, I can think of some “sneak way” of changing stack “on the fly”.
If you playing with setjmp()/longjmp() correct.

Basically before calling a function in question, you setjmp(), store
the orignal sp, feed your own allocated memory to sp, and long jmp
to it.

After returning from the function, setjmp(), restore orignal sp,
longjmp()
to resume oringal stack.

-xtang

begin 666 shim.tgz
M’XL(+ ?73P``^Q=;VP;1W8?1;(MKI6+DCBYW#6-YV0G)16*XE*4Y#]1SK)$ M.4ID2=6?^(K<A:;(I<28XC+<I2Q?8O0*G8NH.K777MH/[9>@'XH"_1*@!UP^ M%09B]'+H%?"'?#BT*7 %6C2%[0I#D8:!>^-S.[W!WNDM1)8MP+)Z9F9_;-
M_WGO_>;-[,18R:TF"^5\OI<F(M&X]'AX4’PF9-]CP<CPW’U.&AV#")JNK@
M<(S0P8.K4L65#3-5HI24=-VL15?O
?]39]CC?S%U1<OF\MK^EQ%5H]&AH;C_
M^ _ N^$!=4B-#D7C0T _$%-50J/[7Y5J]P4?_ZG)^861L=E%)5=(Y\L9C9:T
M=+ED:)'5
\KG7;>6.WA7X?^4BL^1]/Z748?U>&!82’H]%A8’S@?S4ZW.+
M9KC^?J6_G]+J6NIOOF%,)TLI%G$F%Z\5LHMKY@T.!;BKPV3O0Y3&"8UE3* M"4MH/",FS\JSBL(?DVFSE$^:U!$ZJRC]O51;+^HE4\M0X]KJDIZG6;U$<WI? M03-I;[^2TY/PE,SD\TFM8):N00YR%!VARFL*!1<+4^:/JO-81JZ0,]TQQDK9 MS.A7"U2Y#H5CZ>E4/K^42E^AV7(A;>;T@N&L@*G3LJ&AERN86BF;2FOT:LY< MH9E2;DTK805AMIBYM%6IDK:<,\Q2JF F,4.CTF 6K%0U.3F3G$XL).<2%Y+3 M$XO38_-A9T5+Z\ERT5UWB,*JNR--C"QH8:]&JIZQ,1X[O3@UY7BB7H^BEZJ; M9C=*ZG_6FHG)J87$7/)\8FKF$GV=QTU.3RXD9Z;'$E;$> +_CEIUZ,EH:X4^ M,6<,O4?$YHI53T\YYH\[AG4PCXI"Q:GBF(V&F4F5EG$VBN'*Z.6EO$:S^9'H M69BX"RLY@\(_O5RB>7V9(NQ1UO1<ANI&$B*",/PTKZUI^3 ^Y3+A] H(B5Z8 M*JLI,QR)1$*B"Z#UB5Z:+9YEH6S^Z9$@+RN4RT!GLL@B]%A6+VJ%8$^_N5KL M1VD+W8ML$('">L*T)]5#0SR+7#;(4HSP(0E17DY),\NEB>Y+K(M0=VRP6PQ
MS
LE,LBF[JA032$K]=7X57R?V7_94P=^3\0BSGD//
ZK:DO]-<7N2_\!R MV4)&RZ+0>6[R8O(YY02$<@6M$@%D\]<,4UO%I,B=AH-/T^:UHH9LZF+=G.Z. MTDJE@EY%!055Q>5S2W(<,,FR%'?-Z,=R#7<TR+S^7-8K#E2/9[1')I@WUR52 M?&ZYD&*Y*)@*NPRJ5DZ[]".(E( 0OH:6A_QIKW@+>@H$7(!)*"L.]>%*!I1J M$64B 2A78E4AQSZ5\MC;%FSJ= I@0R.:.8,M,K6&F6.2IVF=B;#KU*70 M(0;+D[1,D/*Z0=DHR#PH5)2IX;IDL=IDH#?29MY16A@U-<VD5S-6HDS*3(6I MD?NV!LU!CY/T@@25,F-*-T@+Q2NHXGK1MS)!Y9*TL]>S6?Z0+:56\UHA:927 MPDHG-V?V+]A:@>U0J:HLY;843E$$QE $68.($;H+(AJJ3L([UJ(]5;@ #O
MFONDR>;+QDKMOD7X%+0R<4Z),)5F99AR=:@7&8
2>C5U-8GC@9+FK&Z7$JF
M=<!2ZZRB:;/(-;;+X:3’%$BQ:BS[4& %<CH;F)1IEAAW@.]%S1L!9992U74K
MK^IEP#3Z%1KTSQ62V8RJ%<JKA<D&29(8HS0_R)>6T]KK#-&1!VBZVHT[*(H ME?32B*.6T?68F^)JJE0837BH!AP4^0
6=V9!5#$W130XK3F+F7036’A7DX*
MR"2Z/N2F* (\1KQ=7BUB+%(,NRD0SMK@103W(&T</84].+N4-59Y02P3B[; M,CTTR\GX+PG+,F.?06 ]^U\\KEKX3XT-HOTOK@X-M/!?,]S>\!_(6*U48+JQ M:N7.YU,01:E8A8$F,$P+^" ASC6:K$R\)3UOO/2MR@+SM1XY5U@L/>53TG4N MHU[CJUK\>YTM:"U(.CXUE12P%(V>7'95K43EZORZ2Z(*_Z?UU56]$%F]LN]E MU+/_J<-Q>_T75^.X_AL8'FSQ?S.<6,#]]MC,],3D!47X(Z\"KV9SR[@+P!6R MM90Y&10D(469'KV8&'$PD')B<3Z!%I&1D\'9N9GG$V,+R;F9F850_\G@/ 0F M9Z;Q$9.%(F5#4Q+?6)@;3<[/C;TX.[KP'/#]R: [*EE)".7Q=Y/3#G)W,95* M0@8L+EDP]5 _-]\9_; ^!-0].Y=PEPD1$NE5^A:JA2&4"X/0HW"(N)D,71
MNC,TNVLV!%0"(,O !+6FA< 1>U[FL:DPB"8[HSZ];-)E=V;@ ME!-3XQ-3HQ?FZ=,CM.]2/MS7!U5<TJ%7''U]\07LSGE1[*NKJ71)-W!0E%Q6 M>Y4&[=IBB>[ZAI3QQ/G%"]# OF5E<GI^871J:GQR#L+],&3,"*6,C56J,"Z+ MU1$?.4O[BE29FCP_3T<4+0_UY<\T4UHKS5,Q7?S;-RVK)E&:W_IWG 5^<7
MUI
#D]T>#A:P7#VS_-SK4DO_-<'NU_WEL“G]O0KMM<Q&ELF&65,RZ<PJ
M_+5–&‘S#) CBGH;+E4! EXAH[!$E/+T5KUL[,U16M0%-49!9"XWU1*^’*
M$<CTC57-,JRL!V0YF"!R[<L1"Y\[\G !&CZ%VJ!KF@KJ7S6G3R8@VHP2<G3 M]FL%D(+14(3RRO8K^VF7$G@7(Q KEPU<52>F9Q;F%V?%-H)80WLNX\/TU*E8 MF/:X:M,#R#O@V#P(6EF[-@8J_,],1 ?!_G7Y?VA@P.;_@2BS_T?CL1;_-\/M M%_][V.V]#/+E0@ZBF9BP(WLLV=%CRPZ7U1+6C>6"EY1(6%O)%C<X]G(C= (3 M:P9%:Q6*!\!A,-2 3@K+;E;G!B\#N(_1F>OTU;)6UB(6HU>941F?"E.[RY[J M,@KZLNKP8(55688]8NO.XM,H;6SO;C]<A?_1_GL@[%^/_V-#T8K]9V XM78
MT&!K_=<4=P#ZWS(U3E’<)9:E+5.C%CG+1Q&?):A5DIR#<,3"ZIP38RJ-@?
M[11+.(.1B%,Q7X%]1(E#":P/1N7$*%"W5=I?%Z(4.UV4>Z-M*J-$U:+J@T+ MUV8*$R(!=X_TIM0T'B)XRM4U8SM>[:R10@4N%$HO1"5PP6:O6/(":"&&(L;
M?DJ@MLPZ’8W:,NN,LPLBWRR@]%("_?US8EPXM.+HBQV>X7VI!’)9&OR:WR"&
ME "T6ZH&VS3!TM6
Q,12$2 6"KI)[3+'63:,H$%Z0TV*=B\+JK=DS$X\XM MU;.VZ#=74H QH;XP3?'X3TE+:X ->9WE?NY[%F7_TC532\)H!ZGKO:T6HNP? M-T8FS__.0B(Y.[J 1V!H:&0$*E:SO;%Z[3T/I=/9E(G\$Z&^[181B9D74*&X MV40:@BJ6<(\G/P#E'$_!% TP:*,S6IZ%=G?$JR>?5(@U#7&\@KV>(P8]'@AZ ML09NY=HU8:+)BO$8U^HW;.NW.CJ?*M 0?89&0Y6!B6(5K4%2F9+_O(T@%?U? M2ET]&/5??_T?BU?T?QS7_[%!M;7_TQ2G[ T>”. ><X(JB>JKNE(>T$:T0 MZL[FX2CGX5_IB$$C53GM795R013@79_=C+^#_[G..P94(?XRI^\&XFJ
M?/T
$(^W^+\9;O_QOQMDL#-6
*"2.)O4RPQ?XH]U/,KKR0.F3U@+
:LKN?0*
MP#?#"!GH;ARD69+^BK-ZU<!J^13U[22A.#W?/I+V]/Q+P$E+)C?A5#WPA’
M9SXR:I*(Q#=2UA@(R,P:N(T^QGZY#JBQ;!=12K0.SL2S3L2C:LINJH91FI9 ML^(RFF'F"FAK@=51BG<N32WI:QHM&Q$.O+ /^Y[-YE/+!GV*)J=G7UA(7IR_ M8)UA]@'3)AL(;Q#-1X6-@*OW18=7^IEU;PB/34=#E156U1*)E<8.S_F7)XPQ M+NP,6%H)V /FUP:?E4"=1K"9% A(;<%Q81UFE3I"ZRP:5%RB\;+/V.=!^7<% MC(0:&C-^62,*W&*M&_R[J4:3J'/)P6O).JIBR>)]!PI)%@F.DXZ64-@MK[// M.ABWEXO%AKC=]WBEQ6-\Z7T0K*FJGJR)-3KCQ9R<D:P9@?W\*S+HD@:RL"$& ME6<5GC7$FL=\:QZ6:P``(J>M:1EK5M7F%WYLN/;T<O*A8X9A=\Q#[["5:4&[ M:G<!S@E8O>,2W]'^2#W6;:0JSFEM547!R>Z>W!;?R!JOL3F>SFNIM-CJ<(U
MW."J=*T!;4W#
+^J\3E.062@:5M/ITPMXV6KKGE,&-\XS==N’J@WG0>J)X4H
MC8^]HZ^B](BM^5\707_6T?P]W!4.\UY!C_1]78XC_V??+?Q_.X[/]< M(%9_(N*0,;(<O)ABEL9YZWO-.;V,RLS+\"Y_<K([R>6T)%HY5<DLL8SV;H=: M:<A>SS.@GA*&<M#H2QJ",YL+:[5=]=R"W%U/#'KTA.K7%?+&;.5SG:9UAL.B MPZ"0O>?K4)IBI[>B+9E=?R6U)A\.6=+P.$F5]O3^(NE@^CHF][6][]M4;5F1 M_^NGA@[H#IC&[G\9B U&U>'H(,K_6"S:NO^E*<X]_@=S!TS=^U_B4?G^%SP2 MU-+_37#L_A=Q;+AU!\P7S[GY/W,@]X#MXOXO%/TH_X<'U9;\;X:K'O_]UP'U M[_^2Y7\\'FV=_VJ*LT1^)-(/_^QOP%IR_POBJOE?K.3U_2NCWOTO<=O^*?
MV7_BVK+_M,4][N)J8FVMC8[W$;:29OC_4<B$&=_@Z2+!,CBYK]O?-3]XOR' M&/72[[W;#MX_)[H^V'@#'O[E+_#OQJU/MC<>@H?9[8UCZ'WXV<[.SN;?;]SJ MOG'7? 1>[Y2[7V21&[=^P1^VM0]?>ODG[[KK=U^=^N]54/TE_-JE.%J#OE/X MV"U1-1)5P<\5B?LS8I(B7C<]$7)A;.P,#5Z87@S16.3T8"1&U=.G3ZO16!S/ MQ^2UE*&%"(D8UU;-U!+X9HG[*]83'ITA$2 53VAMX6'^M&08)%+030TB=1Z% M,ETK[&;N_H9HWV$1QK%_V?&^0_A?@U_ $6]"@G.$CTF;H,/^>EJ$K7Y^"W[? M=Z2CPE>E_'X(^5T6^;4[\CLK?"N_J'/".NJ'=3GBB$>Z8XZPE6Q"/%MS;1P" M(0^Z:<<SNE4(/.5!]R!QSZD?P(M+'G3.,M']%!*]#9%'X;E+M*.;\#YQYO?Z M(4+N>N0G.V=\!_EX1W'%?;SCI&V7<FF7N**='"(/2;GC^%/XA0F7&V[Z(R0" M/@J#3L_WAZ5P)QM_=-CV!R'FO.,]]L.T%'Y9"E^1PM^6PIM2^,^E\-\0/M]. MBO+?(7P,'F/A_]FY)6BQW(>@1?\@I?]7*?P?4OB_I#"QK]Q,)F<GQY))LIQ. MQY+ L$7 WYD(<5YU1[)Y(G^12QQGA(EDMR3.(R#$O75+W)MV<E)5CH@1Y^E8 MXM@/)]SF29(7IF;.CTXE9R8FYA,+R871\U.))&&WWA%Q4QWA-].)MBM?)N0K MX >@@X\+/X@^3)9^X>/ZKP,Z_WGT@7@>_:_R,6F[7\RK+_'Q:GN IV_K%O,1 MF!#Q0]M#7'ZU/4Q(!GU(M"+\O/"+Z#\"\@O]#O*%<M7X3WP'W#S\IPX/.O'? M%O_J:WO?YOBZN$
(N&H!U#/=<&C5N?;6]@>’:E!.%7+C-$]PZ.X-:W
M/@10YX6;7)^K’A@XVA=(Y(F)!ASO_3#1^^U<?P1(;4PDW[ADY:<2-];QHQLB
M;JR#=%Y8YQGBQAVOP^]+'G3CQ(T?H TAG7>AM]%#SH9Z[P#@=N$8SN%^&.=
M-R PY9&?[/87ZW1481WW>QF[’)+"1]@\0(=S!+&“TZR*[4Q(86)?O^”#!=S,
MXJUOA3(&54B4HV+>P:1X$ONDBWBZ:OG/OP/?1
%?7
['G?(?[
^)XS5@+?G?
M!%=/G\B,;E_Y6*%=O,N%?0:SR78OBWXON>^<EWYR_Z<-ROV,5)Z?W/>C
MD^4^TC4B]]?A=[‘G2SW;Y#&Y#ZNG1J1^V\W*/>T\YQOYR?[&2Y’R![D_L/
M^N;>F-RGXAGG",K]/L=[;.>8%";6M1NUQ3[GDYI2G^Q*[ENN6OZSSWKW4_S7
MM?]&7?*?[?]$6
>-<?5D]O"N:MDO^2_7=KL7/K8M=6HGOK;S%V_#FBQV;
MT]T.O?#=BE[X<(F@RNB^<;/,.@C.(&4-P9W+R[<>L76X=?:7N%X’[:YU;
MYZ([MS=NT8U/=LPCZLT[3VRO<85SF27[?<R8@7’3L6.O’G7LYZL>BSU6RSU
M&Y746.ZCVQ-?FMV>Z()?Y^P.(]Y9Z]@Z_]C.[1LW7P^@WUSIV/SKGJS8J[V
MTF^6_IF7JEZ7_.K]IHF[EU)>Z93^W/JI5[635[ZN;['9/73S??.L3M?/5T
M[B/75G6S7YTLFX>][$_R[KY,@1N.NBHE9ZX-1
]KS’=/’%?8[IYJH-‘XD0Y
M2OQU]0ACA_D_&0GZ^9.LC?=W.V;.]?-:$?:AIK%WR^VI=/22>XIP72W;
MF[\AA3-26+8W$W&%3FU5+K&8RX;KK> ][TN>RRSIW9Q.VK[_1Q[H/X?;\# M%O=S(KPI_#\3\>^(='\GTOU8O']?O+^#\0^0EOLU=M7X#^^!V%?X5_?^I]B M$_^Q[[_Q2H@6_FN"JX?_S%W;?[]7M?[WHZ>,?KLA>X&?\[NH0?%_7[D]X=Z& M-Y[XYK+CO1^^R7<('4!JXYLWI?+\\(T?G8QOD*X1?',3?E]WT%'AR_@&4(C
M^.;)ML;P31@2_9S4MSUT=;C[N5%<X3L#=^X5>WN;0]/B&?+]A!QO,=VCDOA
M%P2M14_X%4!UX(O@L-K&"
;4’SM$U\7<^)^$52WV[1<OOC//2_N =F_S!
M/?L/N
/1/O^-]S_&!^,M^T]37#W]TTAIJKT^.7),-XK’L9N76XN/9S<7
M/]M4 A]NE7N>N!'GUZRH(%#U6_ZMY:[+Q[_EBG0[ P-:C#_PH>GL)?C[
MR]FMQ#‘X=<.O<Q;-/^<I,__<N%F^L’‘KDZW#D’".F86".[?OQ-%>9
6’/Y_-
M^N:Q^6,T(NWLF(?5FW>>9NFV-\ZQFOVATPHD%;‘YR;;VLY=>3O[DW>TUWO8N
MN>W7.UE++T1FMS>^PS+(U=3[UZ =C[RKO)7G?7Y^KE’>)%79RYS:SB7]
M,=/’+/D?-XR9&KD0II:!:7<7BE3GU-BM%XUV.7=$XJ<0!QQNJ>1GA?.>[,!
M.U;Q,-GKX?SWFO0CN5’)^.]QJT8_T<@%'GE3X,L[[SP;M6 ^T-X;SC@$T M^F]2'^=U0/^]XI&?[&2<=Y3L#><][)M[8SBO1SS_+VGL; &>G_B,\+F"]"^! MGVESXC[[ZK<ZV(^=)6P(^'D?-.1CBE@/ST4@UCM'.-;[1Q'^)Q%&.R[2/='& MXY]NX_$C(OR\"!N"[G41O]G6PHZ[<=7XS_[H?M\8#W[S\"@$__A__]]$%^W
M%\37#W]]U=VW
^I&’[#L^9.4’#=,Z4/O?[ZD<MV"4A6C5D?%[FF8X(D3
MG-]1^.&$MSK$VIK4Q@FWB-OYX00
.ADG(%TC…%G#OE02?CA.ZVQG#“4(/V
MH&?:&,)87A1\LA/=C).Z”)[PPG’7#&[QPDGQ+.EYYWG5;&=DU)XEKCM02G"
M[6 V3G!<$54;*-@?(32"%6I=N!IL7/9J2+^'41?X.T$ MYWG^W_DIVSXX
MU/
^W
^KPX,Q5?K^?S ^T#K_V10GZ
]V(9FFCG#]\IQ8K,1A]=8!^O\Q\DB5
M_,-O;#’)% WEU04PO0X^$>TO?:A-[JYCX_P.RG^HP_"'[SO$S\JSS6$4 M%\<3F QPSHWC'NU">?&;CG!0^&@31[GX6X3KR4<)UX-/$+=#7?M5XOX.$-=9 M7Q'/UKD^J#Y;C^$W1U_VJ,=^N4?JO'^\P7R<^A/[\:0CW.N3YH?"MW16]WU6 MF#]T'[+"7(?E#UMAC@P^L,.<\",[S!\ZCEAA_M!EASFRF[+#'-4L=%EA;C>Z M;(>/,M^:,^V$OZ#'K3 _\?J^'>9?/GQ@AWG"?[/#_,0)SE$>YJ=#W[3#[J\$ MVJ65?3MH<#Q;\M9QZYO"^TD6_-N*M18/L#,:F4[K#$J XS.1_X. &?X4_/>. M6CHX0,)ME?;C^S+XIQSOJ:,_'X+^Q.]$S8 C/?CGCEO?6/Y?>]<>&T41QG>/ M1WM'H8!2,)JPHC&^:$EI@38DFV)1L &B)%’/.]NK[VSU[MR#^",20U0*8 M)FA"% Q:3##!: +ZEXD&$T-\Q";R!XDU5H,)5002C:(</><W\\WM[/:NO:HQ M)=DOM_EV=K^9G=O'['R_WS>S,[7IK+P3ROXOJ.[K>%K3OD&B4HYC\'*N35Z/ M.2S]*=G?3_;-NG5^4#_T,2)*_;;@_'LE=N'EL2:0H"[RGZ;S*\9<SN7WJ_R_ M<]GU?I'I(TIY2QW'\RG7#^FU;/\I9?\PTPV55OZ/<'TJY)A.5C%_ZY8-J]<_ MUE*BZT)Q.AU,3>+AF$4'7MI'D-@"BYW<7E'Z+A8-AEB/H+9>\P>Y:^,/D^+^ MC-_/?!P_WJ;8%#>=8^+9?;]0^!$&Z5;2CY(V24=(QTCWD$Z3/D'Z).E3I-\C M?88T'@;H'*6O,5W!MOT&S5X"UZ'9B^#25=9.G=6T_&FT5_E^Z4_F^W'C\1%7 MPT.(+.U'>Q#![N$!GD8//8*-PQ^SI,-O/<CNX9]K#NW4#O2N1%AJ^]3]A[%R M0,L/B$V]*[3,#]LL7L'*V\[RLAU]?<X8UN4+:*Z%BRS_MZ]=% 3"H=Z7+N?S M[8=Z^Z N;2HVUT*MG&NAS8J1I?*MXUZ83[[V6RA(CN7;91O+Y\QS0N8YS?/0 M^(\6AS^O_(?4?%N\,!YU6[SP("^'XH5OC!2)%\YQBPG'"Z_\!=DH7OC-D?'B MA3^O0;SPHW^WO,-\4+FR-%XX7Q&AX[7KAOU#DW:^@1_D!*'YFRD@I/*1! MVG_([8E4^_JFW5[EYSPUX_%S@VI1^VY.(G[NKBNH&?%S5W(3YN>FSW/P<]MY M@<3/'<LY^;FC?#?Q<R_DRN3GCM].U^1+GIWXN4=RI:YAC[3_D=L39E9=TGZ5 MM/^#VQ,&]MV-4O:SI;WOJF+_;DG[(=9S.=![F;=)^?3=^W\7"=%47>:M5V[_ M8;Y_=RZ?^7Y;X7FQRCAZ&[59EW[]*Y\_*]K0LN=&&>/M-);<ZO'U_S9^S>5W MB=_]QX#OV#)4S+E4!!X0^N^1&<7WXP#H[Z+/CWXZ^J[G2M@6$\Q/%*H2/@X6 M]'6?&:-.\&WP4L.ZU-*?@"QB?=UZMJRI$&7!-\$[ZDY=C -_7-<*<?9\#IH* M,4X0?7#TCN +PHN#SP?O#;X@_N-678P90%YX@>B#X]S@[8E>$CPG^,?P_; . M'Q']_3UL@=<D^UQ<RL/@7:L)615C22;[MK%XEDB O1IJS6R<F0B=3JI386&M M,T%43$^,K7"_3*P*:H9[<04^!NS,$LG7A-*)9(HEA.+EL$,$NJ,AXG(D>R-( MG;(%N!*>'SP;9VC9KEN\A,2_@$W-(#L\8QQSF2*>K7F:Q54\(#8+NVEBV:H
M=’)5SJT%.SQ[6’HH/5.SSZTE[8#;8)DMRU?L6A4[/–8%E"Z4K%;KUF<%=H2
M+.JS+NNW2;$#_E-%L0%2Y’EY2K$##H&E<IK=#O
T8H>V"TNQXYJ:Q0O)-O8-
MA20R2&.NH JR<^2:GDIS>+4./Y9;>%G:GE9Q0YM]OEJ>WD]BCV &G&BQA
MMU>Q0]M[L=HZEK3#<I#."9]/S1 X;)]F\5WRNKVB69P?WA,OSQ;7UWG<5Y7_
M#H’=DT7NOW[-S@W^-,=^7DIQ>:^SE\3;1>R<7%XE>[E<FR;>,:U::2[O.O/0
MMB@92W%Y$!?WE.F)XY[V]#Q’NL:1GL_/L,J5JOPUN%3G?M3@>J$?Y>7MY0#5
M7V?%]CVA4)ZEE:OV’N8/7C#E556&NW/>24_N,^A0KIZ5/WB9=1O7>&&%4S
ME/+Q
\JY>]5[%&?8TSO4]HW[U*_I.V^L[2/BBC/L>5^@#W1#_R82H/N.^Y MA7*NOIG:5V649S5$7L[ACV??H-@/E6%O*O:82Z_**\=V>K61,O*GO5;^J?KX M]N<5^UEEV$>4^^.W8[SWZ?;<?Y&W8[SK];M.#BV52<?YL#YP<^KN+.W0[
MSK]+M^/>W4[SG
$@?.0W]&XOSO(ZW@)\X</[/R%[B_ ,.W’U0M^/\F#=6 MQ?G_I/P2YT<3JN+\51X[SC_78\?Y[_'8C_>@QX[SK_+8<?XVCQWGW^AQXOP4 MP!!*IIF;6QMR1C+TU"YE-BV;G]CH;]O0R@S]S-‘T=\82P4#,SWN’_D!F-Q_R
MZS<SW=U9K2.1#(7]Z82?X/!6
R[2)!Y_B)P@F
’=Q<<A9J%0M$OI4
I"F1>
MF##2.3-D8?8H.9T(#44N,>98#/2QPCZ5P X;M5"<IQ 4B.1)1I$31 LX2 T;
MU(@&DI1’;F01(9CCFP! LAN Z5?1B3>B$R1"5-!)LSBG61O$9Q’@@,APVE
M*DS#<DN)%?^QL6UUZ_JVVO3N_SS,8;SY_QN7%+[O’Q9/1__6[,C?_X7V1-
M)AKC(!_J%9[,O%L.)1N]FV.A(T>D3!2D40F9AI!MB46"(5-(QHWD:J)QR* M=D1#AAEE[0AKNK)&(&5T)&*QQ*Y4L\_PU652R;I4,E07-\TN_T[FT2\1R72B MSDRR=B>9XK%&=;@%?;Y,?#$N!+[?Q=NX=.=SXEN>K%K*(>*FD4UDC$"2F873 ML# 3QJ+N0%>858M=REALD<^W%I] C6>-!"LM:>S(X-.HB7BJ+AGN#B2[4D9W MUF!KT9@1334;P<Y ,)!=U2T^<0>_WK<Y'&LV'FI:7K^X:7%3XS)\C]#7$H[) MC8V-[-=4W[#"Q\Y3(-Z5<K^6X(HKKKCBBBNNN.***ZZXXHHKKKCBBBNNN.+* ,))._7I?=PR ``
end

Xiaodan,

We (me and Rony) tried the code sample you wrote below on x86 machine inside
our driver and it works perfectly.
The problem is that I can’t find the correct address for ppc.
Could you please help me on this one?
Thanks


Cheers

Benzy Gabay
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:a3l28k$d2m$1@nntp.qnx.com

Rony Shapiro <> rshapiro@maya-st.com> > wrote:

Hi Xiaodan!
I think that “sneaky” is definitely in order at this stage!
Can you give me a code snippet showing what you meant. I get the general
idea, but I’m not sure, for example, how to manipulate the sp in the
manner
you describe.

Also, this has to be both for x86 (for development/testing) and for
PowerPC
(production).

I don’t have document in hand, but here is what in my mind:

char * mystack = malloc(mystacksize);
jmp_buf env;
void *stored_sp;
char *esp;

/* before call into a function /
if (setjmp(&env) == 0) {
/
this part is different between PPC and X86

  • check ansi/$(CPU)/_jmp.S
    */
    esp = (char *)env + 0x2c;

stored_sp = *(int *)esp;
*(int *)esp = mystack + mystacksize - sizeof(int);
longjmp(&env);
}

MyFunctionNeedBigStack();

/* after the call, restore orignal esp */
if (setjmp(&env) == 0) {
esp = (char *)env + 0x2c;
*(int *)esp = stored_sp;
longjmp(&env);
}

For libc source, check cvs.qnx.com.

-xtang

Thanks,

Rony
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:a3ee4o$inp$> 1@nntp.qnx.com> …
[…]
: If I understand you correctly, there’s no effective way to “clean
up”
our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more
difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work
in
this
area since 6.1. Don’t discount libc functions. Some of them have
been
found
to be stack hungy as part of the above exercise.

Well, I can think of some “sneak way” of changing stack “on the fly”.
If you playing with setjmp()/longjmp() correct.

Basically before calling a function in question, you setjmp(), store
the orignal sp, feed your own allocated memory to sp, and long jmp
to it.

After returning from the function, setjmp(), restore orignal sp,
longjmp()
to resume oringal stack.

-xtang

Benzy Gabay <bgabay@maya-st.com> wrote:

Xiaodan,

We (me and Rony) tried the code sample you wrote below on x86 machine inside
our driver and it works perfectly.
The problem is that I can’t find the correct address for ppc.
Could you please help me on this one?

Try env + 0x04.

-xtang


Thanks


Cheers

Benzy Gabay
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:a3l28k$d2m$> 1@nntp.qnx.com> …
Rony Shapiro <> rshapiro@maya-st.com> > wrote:

Hi Xiaodan!
I think that “sneaky” is definitely in order at this stage!
Can you give me a code snippet showing what you meant. I get the general
idea, but I’m not sure, for example, how to manipulate the sp in the
manner
you describe.

Also, this has to be both for x86 (for development/testing) and for
PowerPC
(production).

I don’t have document in hand, but here is what in my mind:

char * mystack = malloc(mystacksize);
jmp_buf env;
void *stored_sp;
char *esp;

/* before call into a function /
if (setjmp(&env) == 0) {
/
this part is different between PPC and X86

  • check ansi/$(CPU)/_jmp.S
    */
    esp = (char *)env + 0x2c;

stored_sp = *(int *)esp;
*(int *)esp = mystack + mystacksize - sizeof(int);
longjmp(&env);
}

MyFunctionNeedBigStack();

/* after the call, restore orignal esp */
if (setjmp(&env) == 0) {
esp = (char *)env + 0x2c;
*(int *)esp = stored_sp;
longjmp(&env);
}

For libc source, check cvs.qnx.com.

-xtang

Thanks,

Rony
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:a3ee4o$inp$> 1@nntp.qnx.com> …
[…]
: If I understand you correctly, there’s no effective way to “clean
up”
our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more
difficult
than under 6.2. As you’ve probably guessed, I’ve done a little work
in
this
area since 6.1. Don’t discount libc functions. Some of them have
been
found
to be stack hungy as part of the above exercise.

Well, I can think of some “sneak way” of changing stack “on the fly”.
If you playing with setjmp()/longjmp() correct.

Basically before calling a function in question, you setjmp(), store
the orignal sp, feed your own allocated memory to sp, and long jmp
to it.

After returning from the function, setjmp(), restore orignal sp,
longjmp()
to resume oringal stack.

-xtang

Xiaodan,

while using env+0x04 on ppc, I’m coring…
and on x86, with the same driver code (minimal code, just rx_up/down on my
rx/tx functions) and using 0x2c it is working perfectly.

any idea?

Cheers

Benzy Gabay
“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:a4gnjr$4r7$1@nntp.qnx.com

Benzy Gabay <> bgabay@maya-st.com> > wrote:
Xiaodan,

We (me and Rony) tried the code sample you wrote below on x86 machine
inside
our driver and it works perfectly.
The problem is that I can’t find the correct address for ppc.
Could you please help me on this one?

Try env + 0x04.

-xtang


Thanks


Cheers

Benzy Gabay
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:a3l28k$d2m$> 1@nntp.qnx.com> …
Rony Shapiro <> rshapiro@maya-st.com> > wrote:

Hi Xiaodan!
I think that “sneaky” is definitely in order at this stage!
Can you give me a code snippet showing what you meant. I get the
general
idea, but I’m not sure, for example, how to manipulate the sp in the
manner
you describe.

Also, this has to be both for x86 (for development/testing) and for
PowerPC
(production).

I don’t have document in hand, but here is what in my mind:

char * mystack = malloc(mystacksize);
jmp_buf env;
void *stored_sp;
char *esp;

/* before call into a function /
if (setjmp(&env) == 0) {
/
this part is different between PPC and X86

  • check ansi/$(CPU)/_jmp.S
    */
    esp = (char *)env + 0x2c;

stored_sp = *(int *)esp;
*(int *)esp = mystack + mystacksize - sizeof(int);
longjmp(&env);
}

MyFunctionNeedBigStack();

/* after the call, restore orignal esp */
if (setjmp(&env) == 0) {
esp = (char *)env + 0x2c;
*(int *)esp = stored_sp;
longjmp(&env);
}

For libc source, check cvs.qnx.com.

-xtang

Thanks,

Rony
“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:a3ee4o$inp$> 1@nntp.qnx.com> …
[…]
: If I understand you correctly, there’s no effective way to
“clean
up”
our
: stack usage, since we can’t find the bottleneck > :frowning:

Not really, other than by trial and error. It’s definitely more
difficult
than under 6.2. As you’ve probably guessed, I’ve done a little
work
in
this
area since 6.1. Don’t discount libc functions. Some of them have
been
found
to be stack hungy as part of the above exercise.

Well, I can think of some “sneak way” of changing stack “on the
fly”.
If you playing with setjmp()/longjmp() correct.

Basically before calling a function in question, you setjmp(), store
the orignal sp, feed your own allocated memory to sp, and long jmp
to it.

After returning from the function, setjmp(), restore orignal sp,
longjmp()
to resume oringal stack.

-xtang
\

Try backing off esp a bit more. See below.

-seanb

Benzy Gabay <bgabay@maya-st.com> wrote:
: Xiaodan,

: while using env+0x04 on ppc, I’m coring…
: and on x86, with the same driver code (minimal code, just rx_up/down on my
: rx/tx functions) and using 0x2c it is working perfectly.

: any idea?
: –
: Cheers
: ==============
: Benzy Gabay
: “Xiaodan Tang” <xtang@qnx.com> wrote in message
: news:a4gnjr$4r7$1@nntp.qnx.com
:> Benzy Gabay <bgabay@maya-st.com> wrote:
:> > Xiaodan,
:>
:> > We (me and Rony) tried the code sample you wrote below on x86 machine
: inside
:> > our driver and it works perfectly.
:> > The problem is that I can’t find the correct address for ppc.
:> > Could you please help me on this one?
:>
:> Try env + 0x04.
:>
:> -xtang
:>
:>
:> > Thanks
:>
:> > –
:> > Cheers
:> > ==============
:> > Benzy Gabay
:> > “Xiaodan Tang” <xtang@qnx.com> wrote in message
:> > news:a3l28k$d2m$1@nntp.qnx.com
:> >> Rony Shapiro <rshapiro@maya-st.com> wrote:
:> >>
:> >> > Hi Xiaodan!
:> >> > I think that “sneaky” is definitely in order at this stage!
:> >> > Can you give me a code snippet showing what you meant. I get the
: general
:> >> > idea, but I’m not sure, for example, how to manipulate the sp in the
:> > manner
:> >> > you describe.
:> >>
:> >> > Also, this has to be both for x86 (for development/testing) and for
:> > PowerPC
:> >> > (production).
:> >>
:> >> I don’t have document in hand, but here is what in my mind:
:> >>
:> >> char * mystack = malloc(mystacksize);
:> >> jmp_buf env;
:> >> void *stored_sp;
:> >> char esp;
:> >>
:> >> /
before call into a function /
:> >> if (setjmp(&env) == 0) {
:> >> /
this part is different between PPC and X86
:> >> * check ansi/$(CPU)/_jmp.S
:> >> */
:> >> esp = (char *)env + 0x2c;
:> >>
:> >> stored_sp = *(int *)esp;
*(int )esp = mystack + mystacksize - sizeof(int) - 4sizeof(int);

:> >> longjmp(&env);
:> >> }
:> >>
:> >> MyFunctionNeedBigStack();
:> >>
:> >> /* after the call, restore orignal esp */
:> >> if (setjmp(&env) == 0) {
:> >> esp = (char *)env + 0x2c;
:> >> *(int *)esp = stored_sp;
:> >> longjmp(&env);
:> >> }
:> >>
:> >> For libc source, check cvs.qnx.com.
:> >>
:> >> -xtang
:> >>
:> >> > Thanks,
:> >>
:> >> > Rony
:> >> > “Xiaodan Tang” <xtang@qnx.com> wrote in message
:> >> > news:a3ee4o$inp$1@nntp.qnx.com
:> >> > […]
:> >> >> > : If I understand you correctly, there’s no effective way to
: “clean
:> > up”
:> >> > our
:> >> >> > : stack usage, since we can’t find the bottleneck :frowning:
:> >> >>
:> >> >> > Not really, other than by trial and error. It’s definitely more
:> >> > difficult
:> >> >> > than under 6.2. As you’ve probably guessed, I’ve done a little
: work
:> > in
:> >> > this
:> >> >> > area since 6.1. Don’t discount libc functions. Some of them have
:> > been
:> >> > found
:> >> >> > to be stack hungy as part of the above exercise.
:> >> >>
:> >> >> Well, I can think of some “sneak way” of changing stack “on the
: fly”.
:> >> >> If you playing with setjmp()/longjmp() correct.
:> >> >>
:> >> >> Basically before calling a function in question, you setjmp(), store
:> >> >> the orignal sp, feed your own allocated memory to sp, and long jmp
:> >> >> to it.
:> >> >>
:> >> >> After returning from the function, setjmp(), restore orignal sp,
:> > longjmp()
:> >> >> to resume oringal stack.
:> >> >>
:> >> >> -xtang
:> >>
:> >>
:>
:>

tried it…but still…
anymore ideas ?


Cheers

Benzy Gabay
“Sean Boudreau” <seanb@qnx.com> wrote in message
news:a4jvlj$jat$1@nntp.qnx.com

Try backing off esp a bit more. See below.

-seanb

Benzy Gabay <> bgabay@maya-st.com> > wrote:
: Xiaodan,

: while using env+0x04 on ppc, I’m coring…
: and on x86, with the same driver code (minimal code, just rx_up/down on
my
: rx/tx functions) and using 0x2c it is working perfectly.

: any idea?
: –
: Cheers
: ==============
: Benzy Gabay
: “Xiaodan Tang” <> xtang@qnx.com> > wrote in message
: news:a4gnjr$4r7$> 1@nntp.qnx.com> …
:> Benzy Gabay <> bgabay@maya-st.com> > wrote:
:> > Xiaodan,
:
:> > We (me and Rony) tried the code sample you wrote below on x86 machine
: inside
:> > our driver and it works perfectly.
:> > The problem is that I can’t find the correct address for ppc.
:> > Could you please help me on this one?
:
:> Try env + 0x04.
:
:> -xtang
:
:
:> > Thanks
:
:> > –
:> > Cheers
:> > ==============
:> > Benzy Gabay
:> > “Xiaodan Tang” <> xtang@qnx.com> > wrote in message
:> > news:a3l28k$d2m$> 1@nntp.qnx.com> …
:> >> Rony Shapiro <> rshapiro@maya-st.com> > wrote:
:
:> >> > Hi Xiaodan!
:> >> > I think that “sneaky” is definitely in order at this stage!
:> >> > Can you give me a code snippet showing what you meant. I get the
: general
:> >> > idea, but I’m not sure, for example, how to manipulate the sp in
the
:> > manner
:> >> > you describe.
:
:> >> > Also, this has to be both for x86 (for development/testing) and
for
:> > PowerPC
:> >> > (production).
:
:> >> I don’t have document in hand, but here is what in my mind:
:
:> >> char * mystack = malloc(mystacksize);
:> >> jmp_buf env;
:> >> void *stored_sp;
:> >> char esp;
:
:> >> /
before call into a function /
:> >> if (setjmp(&env) == 0) {
:> >> /
this part is different between PPC and X86
:> >> * check ansi/$(CPU)/_jmp.S
:> >> */
:> >> esp = (char *)env + 0x2c;
:
:> >> stored_sp = *(int *)esp;
*(int )esp = mystack + mystacksize - sizeof(int) - 4sizeof(int);

:> >> longjmp(&env);
:> >> }
:
:> >> MyFunctionNeedBigStack();
:
:> >> /* after the call, restore orignal esp */
:> >> if (setjmp(&env) == 0) {
:> >> esp = (char *)env + 0x2c;
:> >> *(int *)esp = stored_sp;
:> >> longjmp(&env);
:> >> }
:
:> >> For libc source, check cvs.qnx.com.
:
:> >> -xtang
:
:> >> > Thanks,
:
:> >> > Rony
:> >> > “Xiaodan Tang” <> xtang@qnx.com> > wrote in message
:> >> > news:a3ee4o$inp$> 1@nntp.qnx.com> …
:> >> > […]
:> >> >> > : If I understand you correctly, there’s no effective way to
: “clean
:> > up”
:> >> > our
:> >> >> > : stack usage, since we can’t find the bottleneck > :frowning:
:
:> >> >> > Not really, other than by trial and error. It’s definitely
more
:> >> > difficult
:> >> >> > than under 6.2. As you’ve probably guessed, I’ve done a little
: work
:> > in
:> >> > this
:> >> >> > area since 6.1. Don’t discount libc functions. Some of them
have
:> > been
:> >> > found
:> >> >> > to be stack hungy as part of the above exercise.
:
:> >> >> Well, I can think of some “sneak way” of changing stack “on the
: fly”.
:> >> >> If you playing with setjmp()/longjmp() correct.
:
:> >> >> Basically before calling a function in question, you setjmp(),
store
:> >> >> the orignal sp, feed your own allocated memory to sp, and long
jmp
:> >> >> to it.
:
:> >> >> After returning from the function, setjmp(), restore orignal sp,
:> > longjmp()
:> >> >> to resume oringal stack.
:
:> >> >> -xtang
:
:
:
: