Porting jsnativestack.cpp

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Porting jsnativestack.cpp

maddy-15
Hi
  My platform does not support getting the stack base address of a
thread. I cannot port GetNativeStackBaseImpl API. What will be the
implications of this? How can I overcome this problem.

Madhavan
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting jsnativestack.cpp

Andreas Gal-3

What platform is that?

Andreas

On Apr 17, 2011, at 8:22 AM, maddy wrote:

> Hi
>  My platform does not support getting the stack base address of a
> thread. I cannot port GetNativeStackBaseImpl API. What will be the
> implications of this? How can I overcome this problem.
>
> Madhavan
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting jsnativestack.cpp

Wes Garland
On 17 April 2011 13:29, Andreas Gal <[hidden email]> wrote:

>
> What platform is that?
>

I wonder if it's one of those security-oriented distros that does
address-space randomization -- same ones that broke the crazy mmap loop in
jemalloc and jsgcchunk.cpp

If that's true, then it's possible that this particular distro has per-proc
switches or something which allow things like that to be turned off.. Hmm..
You know, I bet Java would have the same issues.  Maddy, do you have to do
anything interesting on your OS to run a JVM?

Also, maddy, what is your goal? Are you trying to port a browser, or an
embedded JS product?

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting jsnativestack.cpp

maddy-15
In reply to this post by Andreas Gal-3
On Apr 18, 1:16 am, Wes Garland <[hidden email]> wrote:

> On 17 April 2011 13:29, Andreas Gal <[hidden email]> wrote:
>
>
>
> > What platform is that?
>
> I wonder if it's one of those security-oriented distros that does
> address-space randomization -- same ones that broke the crazy mmap loop in
> jemalloc and jsgcchunk.cpp
>
> If that's true, then it's possible that this particular distro has per-proc
> switches or something which allow things like that to be turned off.. Hmm..
> You know, I bet Java would have the same issues.  Maddy, do you have to do
> anything interesting on your OS to run a JVM?
>
> Also, maddy, what is your goal? Are you trying to port a browser, or an
> embedded JS product?
>
> Wes
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102

Hi Wes
   We are trying to port a browser on an embedded platform.
Unforunately there is no support to get the native stack base pointer.
How can we port GetNativeStackBaseImpl? What will happen if this API
is not ported?
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting jsnativestack.cpp

Wes Garland
On 19 April 2011 06:46, maddy <[hidden email]> wrote:

> On Apr 18, 1:16 am, Wes Garland <[hidden email]> wrote:
> Hi Wes
>   We are trying to port a browser on an embedded platform.
> Unforunately there is no support to get the native stack base pointer.
> How can we port GetNativeStackBaseImpl? What will happen if this API
> is not ported?
>

I am certainly no expert here -- but I suspect you *must* be able to get the
stack address for a given thread to make the stack-scanning conservative
garbage collector work.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting jsnativestack.cpp

Jim Blandy-3
In reply to this post by maddy-15
Would it be good enough to simply take the address of a variable in
'main', and make sure not to touch any JavaScript variables in 'main' at
all (call a function 'inner_main' that does all the real work)?
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting jsnativestack.cpp

Wes Garland
This had crossed my mind as well, jim -- but how does that work for
compartments whose threads are spawned long after main runs?

I have to admit, multithread stack layout is not something I've done a lot
of thinking about.

(...I wonder where errno winds up on his system?)

Wes

On 19 April 2011 11:41, Jim Blandy <[hidden email]> wrote:

> Would it be good enough to simply take the address of a variable in 'main',
> and make sure not to touch any JavaScript variables in 'main' at all (call a
> function 'inner_main' that does all the real work)?
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>



--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Porting jsnativestack.cpp

Jim Blandy-3
You need to supply a separate stack start address for each thread ---
they're separate areas of memory, obviously. So you need to do it for
main, and then in the startup function for each thread.


On 04/19/2011 09:59 AM, Wes Garland wrote:

> This had crossed my mind as well, jim -- but how does that work for
> compartments whose threads are spawned long after main runs?
>
> I have to admit, multithread stack layout is not something I've done a
> lot of thinking about.
>
> (...I wonder where errno winds up on his system?)
>
> Wes
>
> On 19 April 2011 11:41, Jim Blandy <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Would it be good enough to simply take the address of a variable
>     in 'main', and make sure not to touch any JavaScript variables in
>     'main' at all (call a function 'inner_main' that does all the real
>     work)?
>
>     _______________________________________________
>     dev-tech-js-engine mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
>
>
>
> --
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine