[Toybox] [PATCH] Stop renaming the ADDR field to PC on Android.
It's causing confusion, and it's not obvious that anyone's relying on it (and even if they are, let's try to find and fix them first). --- toys/posix/ps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) From 88947e9b1e1b722a5e285daa41e3691ad4ccf49d Mon Sep 17 00:00:00 2001 From: Elliott Hughes Date: Tue, 11 Oct 2016 13:03:50 -0700 Subject: [PATCH] Stop renaming the ADDR field to PC on Android. It's causing confusion, and it's not obvious that anyone's relying on it (and even if they are, let's try to find and fix them first). --- toys/posix/ps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/toys/posix/ps.c b/toys/posix/ps.c index cb57ecf..15acc84 100644 --- a/toys/posix/ps.c +++ b/toys/posix/ps.c @@ -1185,7 +1185,7 @@ void ps_main(void) not_o = "F,S,UID,%sPPID,C,PRI,NI,ADDR,SZ,WCHAN,TTY,TIME,CMD"; else if (CFG_TOYBOX_ON_ANDROID) sprintf(not_o = toybuf+128, -"USER,%%sPPID,VSIZE,RSS,WCHAN:10,ADDR:10=PC,S,%s", +"USER,%%sPPID,VSIZE,RSS,WCHAN:10,ADDR:10,S,%s", (toys.optflags&FLAG_T) ? "CMD" : "NAME"); sprintf(toybuf, not_o, (toys.optflags & FLAG_T) ? "PID,TID," : "PID,"); -- 2.8.0.rc3.226.g39d4020 ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] fun with vfork
Do you have vfork tagged with __attribute__((returns_twice))? AFAIK, that's
the incantation to get gcc to do the right thing for setjmpy functions.
On Oct 11, 2016 4:23 AM, "Rob Landley" wrote:
> While doing the rest of nommu support in netcat -L, I had some variant of:
>
> function()
> {
> int child, blah = 3;
>
> for (;;) {
> crunch(blah);
> child = vfork();
> if (child<1) break;
> }
> thingy();
>
> execlp(stuff);
> }
>
> And gcc's optimizer went "blah isn't used anymore after the for loop,
> I'll trim the stack frame down so the return address in the call to
> thingy() in the child overwrites it, and then when vfork returns it's
> corrupted in the parent and the next call to crunch() goes bye-bye".
> Because gcc's optimizer does not understand vfork()'s impact on
> "liveness analysis". (You can think of vfork() as a setjmp that will
> fork() when it hits the next exec or exit, and then the parent process
> longjmp()s back to the stack until the child. But gcc's optimizer doesn't.)
>
> The fix is to add an unnecessary use of blah to the end of the function
> to let it know it's still %*#(%&& used, but then I need a GREAT BIG
> COMMENT to explain why so it isn't removed in future cleanup passes. And
> every other variable potentially has that same problem.
>
> As usual, I want to punch gcc's optimizer in the face and go "DO WHAT I
> TOLD YOU TO DO, DON'T MAKE STUFF UP!" but it never listens. (Do I have
> to start building everything with -O0? What optimization level gives me
> dead code elimination and nothing else?)
>
> Rob
>
> P.S. I'm always amused by the go/rust/swift developers who haven't hit
> their language with anything like the range of use cases you get in C,
> confidently stating that they have yet to see such strange corner cases
> in _their_ language yet. Uh-huh. There's a reason for that and it's
> probably not the one you think.
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
[Toybox] fun with vfork
While doing the rest of nommu support in netcat -L, I had some variant of:
function()
{
int child, blah = 3;
for (;;) {
crunch(blah);
child = vfork();
if (child<1) break;
}
thingy();
execlp(stuff);
}
And gcc's optimizer went "blah isn't used anymore after the for loop,
I'll trim the stack frame down so the return address in the call to
thingy() in the child overwrites it, and then when vfork returns it's
corrupted in the parent and the next call to crunch() goes bye-bye".
Because gcc's optimizer does not understand vfork()'s impact on
"liveness analysis". (You can think of vfork() as a setjmp that will
fork() when it hits the next exec or exit, and then the parent process
longjmp()s back to the stack until the child. But gcc's optimizer doesn't.)
The fix is to add an unnecessary use of blah to the end of the function
to let it know it's still %*#(%&& used, but then I need a GREAT BIG
COMMENT to explain why so it isn't removed in future cleanup passes. And
every other variable potentially has that same problem.
As usual, I want to punch gcc's optimizer in the face and go "DO WHAT I
TOLD YOU TO DO, DON'T MAKE STUFF UP!" but it never listens. (Do I have
to start building everything with -O0? What optimization level gives me
dead code elimination and nothing else?)
Rob
P.S. I'm always amused by the go/rust/swift developers who haven't hit
their language with anything like the range of use cases you get in C,
confidently stating that they have yet to see such strange corner cases
in _their_ language yet. Uh-huh. There's a reason for that and it's
probably not the one you think.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
