Okay thank you very much :)

Why RISC? Did arm became RISC?

also for some general knowledge, ARM was previously abbreviation of Advanced RISC Machinery.

also for some general knowledge, ARM was previously abbreviation of Advanced RISC Machinery.

Yeah I know I just confused C with R

No offtop here

It's not even about optimization

Clang's lto has a real world impact of just 1%

Google is pushing this change purely because LTO is a requirement to support cfi

It's really just 1%

Verified by several kernel developers on android who've been using lto for almost 2 years now

Think a guy named kdrag0n did one

As for LTO

At present there are issues with thinlto and -Wl,--gc-sections breaking programs

x86 uses thinlto because it's too expensive to do full LTO

An almost stripped down android kernel needs 16-36gb to do full LTO

Clang's aggressive inlining during thinlto can sometimes blow the size of your kernel

It never did

Gcc building the kernel without lto is still faster than clang with lto

Only on x86 BTW

Arm64 needs a hack to boot thinlto

x86 is multiarch inside Linux

There's no arch/amd64

Means it includes the -64 extensions

Please don't nitpick stuff like "amd64 as well" we know that when we're talking about Linux x86 includes the -64 too

It isn't about support at all

Clang gives you little performance at best

At the end of the day GCC compiles the faster binary

That's because it's the only one feasible to use?

Unless you're telling me you can allocate 1 tb of ram to link an x86 kernel

Definitely not that much

Very hard to believe if I must say so

I've been doing CFI kernels for quite a while now

Even if I administer a blind test users will say GCC is outperforming

There's several other developers who've independently reproduced similar results

Ex: @Pappschlumpf

Even with LTO clang doesn't come close

I'm not going to go to a thread arguing about some crsm benchmark honestly

Hi guys, i just had a exam and i had a program to understand. (ive already done it) but there is something buging me with fork and exec, its a small program but i dont understand why it dosnt go into a infinite loop because the exec is calling itself. Anyone mind cheking it? Thanks

We've all seen the horrible effects benchmarks had on real world performance. Example octane

Yeah I mean octane also existed a long time

Benchmarks that live this long finally begin to show flaws

Paste code no screenshot

Paste code no screenshot

Sorry, give me 2 min

That's really interesting

#include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> int main() { pid_t pid; pid = fork(); if(pid < 0 ){ fprintf(stderr,"fork a ecohouer\n"); return 1; } else if (pid == 0) { printf("je suis le fils %d",pid); execlp("chmod","chmod","755","/home/bagama/Documents/school/2020ete_systemdexploi/exec.c",NULL); } else { printf("je suis le parent %d\n",pid); wait(NULL); printf("lenfant a terminer\n"); execlp("/home/bagama/Documents/school/2020ete_systemdexploi/","./exec",NULL); } return 0; }

I mean if if ends up by calling itself why dosnt it go into a infinite loop? And sorry some of the words are in french

I mean if if ends up by calling itself why dosnt it go into a infinite loop? And sorry some of the words are in french

Are you sure it is calling itself?

I don't think you can call exec() on .c files

Eww

I don't think you can call exec() on .c files

Its calling the programe with ". /exec". Also yeah the program is called exec lol

Its calling the programe with ". /exec". Also yeah the program is called exec lol

Is this C or C++?

Is this C or C++?

Its c

int execlp(const char *file, const char *arg, ...);

Yeah it was in the statement i had to chmod the exec.c but in the last else its calling exec on itself

Okay execlp("/home/whatever/.../exec", NULL);

It was in my exam this morning, i had to answer to what would be the output.

I was sure it was going to give me an infinity loop because the program ends up by calling itself, but i tryed and non it dosnt. Thats why i reached to you devs :)

I was sure it was going to give me an infinity loop because the program ends up by calling itself, but i tryed and non it dosnt. Thats why i reached to you devs :)

You can't call exec on a C file unless you've done something weird with binfmt

Okay execlp("/home/whatever/.../exec", NULL);

But that part dosnt work? It is not a c file its a executabl3

But that part dosnt work? It is not a c file its a executabl3

No because

/home/whatever/whatever ./exec

This is how the final command looks. Think this will execute?

The first command is trying to execute a C file. The other is trying to execute a directory

Both are invalid

The first one is chmoding the c file non? And the second one is only the path for the executable

The first one is chmoding the c file non? And the second one is only the path for the executable

That too is invalid

The final command looks like "chmod chmod 755 ....."

Since chmod is specified twice the syntax is violated

+1

Read the code

Okey thank you all for the answers. Also how would i be able to call the program itself with execlp

execlp("chmod","chmod","755","/home/bagama/Documents/school/2020ete_systemdexploi/exec.c",NULL);

That's not right

Regardless of how you look at it

You mention the file name twice?

You mention the file name twice?

Its the path OR the name and it will look itself i think

Guys im just trying to understand the logic :( why it dosnt go into a infinity loop.

Yeah thanks as if we call exec() inside the kernel

Very cool

How would i call it without the path with execlp?