Kernel Developers Debate Having An Official Linux System Wrapper Library

[Weasel]

This is your mistake. Static effects the asm of the object does not in fact alter the linkers decisions.
https://en.wikipedia.org/wiki/Static_(keyword)

Obviously it affects the object file by marking the symbol not visible or in some other way (depends on the object format).

At this point, I REALLY don't think you know what symbols are if you think that they have anything to do with compilation (no, symbols, visibility, is ONLY for the LINKER; headers don't give symbols, they only give declarations which is a completely different thing, not like you know that of course).

Both inline and static are defined as "file scope". This means these don't effect a generic linker decisions at all. Yes inline/static change the contents of the object file but they have no effect on the linking process. Extern is the only 1 out of the three that have any effect on generic linker. The inline/static just effect the machine code inside the object unless you use LTO or equal so these are pure compiler processed.

I'm sick of your verbal technobabble diarrhea.

https://stackoverflow.com/a/4193698

Read this closely: Inline functions by default have external linkage.

How the linker treats inline functions is a pretty much implementation level detail. Suffice it to know that the implementation accepts such mulitple defintions within the limitations of ODR rules.

Do you need better glasses to read the word LINKER or what?

This shows what level idiot Weasel is.
int main(){
int x;
}
So by this idiot logic the int x here is a specifiers for the linker. Of course to every who knows coding this int x absolute not a specifiers for the linker. Yes calling inline and static specifiers for the linker is just as dumb as.

That's a local variable which has no linkage at all so it doesn't affect linker at all because it's not aware of it.

Just because you're incapable of logic doesn't mean you have to extrapolate it on me because I'm not a retard like yourself, so don't talk in my name or in my logic's name. Moron.

[oiaohm]

https://stackoverflow.com/a/4193698

Read this closely: [B]Inline functions by default have external linkage.

Please read the standard.

https://en.cppreference.com/w/cpp/language/inline

1. There may be more than one definition of an inline function or variable (since C++17) in the program as long as each definition appears in a different translation unit and (for non-static inline functions and variables (since C++17)) all definitions are identical. For example, an inline function or an inline variable (since C++17) may be defined in a header file that is #include'd in multiple source files.

Here is point 1. Since C++17 the standard has stated that inline per translation unit(object file). Before C++17 C standard defined it this way but it was undefined in the C++ standard. So no it does not have external linkage by default.

3. An inline function or variable (since C++17) with external linkage (e.g. not declared static) has the following additional properties:

1) It must be declared inline in every translation unit.

2) It has the same address in every translation unit.

Hmm lets read this carefully. Must be declared inline in every translation unit this means now inline means does not have exported in object file. Some compilers had been doing this since 1996.

So inline with external linkage by standard is now implemented purely by compiler internal linkage. So nothing to-do with the linker.

You get idiots answering on stackoverflow like you complete morons. A inline function or variable may not have external usage if it does not have external it will be 100 percent solved inside object file and never seen by the linker.

The inline with external linkage is the linker exposed is optional and its compiler choice up until C++17 when its now basically breach of standard. C++17 and new inline is pure internal linkage processing(this is compiler) with rule to use in the case inline appears as external usage to make it cease to exist as external.

Linker is processing exported stuff for external usage.

Inline and Static in the newer standards are pure compiler internal linkage nothing to-do with linker. In the older standards this was undefined so compilers suites could implement them in linker.

Weasel people mix up linkage and linker. Linkage does not always mean linker. Particularly in cases like this where it goes and says that external linkage usage has to be inlined out of existence and that each object file has to support different defines of inline function. Yes exporting inline to the import/export table that the linker processes will result in function conflicts that point 1 of the standard forbids. So inline has to be solved by compiler not linker.

[Weasel]

Please read the standard.

https://en.cppreference.com/w/cpp/language/inline

1. There may be more than one definition of an inline function or variable (since C++17) in the program as long as each definition appears in a different translation unit and (for non-static inline functions and variables (since C++17)) all definitions are identical. For example, an inline function or an inline variable (since C++17) may be defined in a header file that is #include'd in multiple source files.

Here is point 1. Since C++17 the standard has stated that inline per translation unit(object file). Before C++17 C standard defined it this way but it was undefined in the C++ standard. So no it does not have external linkage by default.

Translation Unit is not "object file", it's the source code that results in the object file. https://en.wikipedia.org/wiki/Transl...programming%29

Learn to separate source code from binary already.

3. An inline function or variable (since C++17) with external linkage (e.g. not declared static) has the following additional properties:

1) It must be declared inline in every translation unit.

2) It has the same address in every translation unit.

Hmm lets read this carefully. Must be declared inline in every translation unit this means now inline means does not have exported in object file. Some compilers had been doing this since 1996.

I'm amazed at what kind of wrong crap you can "conclude" from some text you read. You are really a lost cause.

Again, let's read this carefully, as you said.

1) It must be declared inline in every translation unit. (ok)

Declaring it inline means this:

inline int function();

// or both declaration and definition
inline int function() { return 0; }

That's it, you don't even have to call it. For crying out loud, the inline keyword has nothing to do with the process of inlining. The function CAN STILL GET exported, if e.g. its address is taken or the compiler doesn't want to inline it or can't inline it (proof provided below).

So inline with external linkage by standard is now implemented purely by compiler internal linkage. So nothing to-do with the linker.

NO. The compiler may EXPORT THE FUNCTION and mark it inline so the linker knows to discard all of them except for one.

Declaring a function inline does NOT force the compiler to inline it. Get it already. The inline keyword has nothing to do with the compiler inlining it, either, according to the standard (but the compiler is free to inline however it pleases though).

Inline variables have the same semantics. How do you "inline" a variable?

It may not always be exported though, if the compiler decided to inline it everywhere, because then it assumes other translation units (source code) have it declared inline as well, so they have their own copy of it.

You get idiots answering on stackoverflow like you complete morons. A inline function or variable may not have external usage if it does not have external it will be 100 percent solved inside object file and never seen by the linker.

No you are the retard who doesn't even code just do the world a favor and either go to school or shut the hell up already.

Proof on godbolt

Function is exported, as you can see, because it wasn't inlined. It's still in the object file (see asm output), ready to be used by other code that imports it.

If another translation unit uses this same header (assuming it's a header), it will also export it, and then it's the LINKER'S DAMN JOB to discard all except for 1. Now STFU or bring proof.

[oiaohm]

Function is exported, as you can see, because it wasn't inlined. It's still in the object file (see asm output), ready to be used by other code that imports it.

Function is exported, as you can see, because it wasn't inlined. It's still in the object file (see asm output), ready to be used by other code that imports it.

If another translation unit uses this same header (assuming it's a header), it will also export it, and then it's the LINKER'S DAMN JOB to discard all except for 1. Now STFU or bring proof.

Really you will be thinking by this point you have won sorry you have miss used godblot. Give a moron a tool and they will miss use it wrong.

https://gcc.godbolt.org/#g:!((g:!((g...9),version:4

In this mode you will notice that the code in fact alters when you remove/add inline. Also in this mode you can see that godbolt is static linking into a single file. Not building a linkable object.

https://stackoverflow.com/questions/...-gas-assembler
Yes a linkable object anything linker processes has to have a .global declare. When you in fact link and make a object with a function that is inline the .global declare disappears so linker no longer sees functions that are inline. Inline variable also has the interesting effect of making that variable local to object removing the ,global declare.

Yes inline does two things. 1 tells the compiler to consider inline merging function. 2 remove the .global declare from function so making function no longer exist to linker.

[Weasel]

Really you will be thinking by this point you have won sorry you have miss used godblot. Give a moron a tool and they will miss use it wrong.

https://gcc.godbolt.org/#g:!((g:!((g...9),version:4

In this mode you will notice that the code in fact alters when you remove/add inline. Also in this mode you can see that godbolt is static linking into a single file. Not building a linkable object.

You linked the same thing I did, so idk what you are talking about. If you mean the "binary" mode then of course it's not linkable since it's the binary result. Static libraries are a single file (collection of .o files) and totally linkable. Like using those buzzwords?

https://stackoverflow.com/questions/...-gas-assembler
Yes a linkable object anything linker processes has to have a .global declare. When you in fact link and make a object with a function that is inline the .global declare disappears so linker no longer sees functions that are inline. Inline variable also has the interesting effect of making that variable local to object removing the ,global declare.

The .global "declare" is a fucking assembler-specific (GAS only) directive to tell it to export the symbol name in the object file. WTF are you even saying? It doesn't "exist" in the object file any more than a piece of source code exists there (it doesn't), it's an assembler directive and has nothing to do with any of this.

Yes inline does two things. 1 tells the compiler to consider inline merging function.

The compiler always considers inlining decisions on its own, given enough optimization levels (same with inline, you need optimizations turned on for "inlining" to happen). If a function is called only once, it's almost guaranteed for it to be inlined.

But that is irrelevant, since what a compiler does and its heuristics is completely irrelevant to what the keyword does as specified in the god damn standard.

2 remove the .global declare from function so making function no longer exist to linker.

That would make it have internal linkage which is not the case. inline is not equivalent to static nor does it force static. In fact, "static inline" is an extension and isn't even standard. inline functions have external linkage by default.

An inline function is shared in the linked output, it's only duplicated in each object file (if it is not inlined by the compiler, as the example I gave above). The linker then picks just one and discards the rest.

The same with inline variables. The linker picks just one out of many translation units that each duplicate it. Yes, inline variables are a thing in C++. No, they don't get "inlined" because they are not code. They don't affect code generation. They have the same semantics as normal inline keyword.


In other words, "inline" is exactly what happens with ELF's retarded global symbol namespace, except that instead of the dynamic runtime loader, you have the static linker at compile time, which probably picks the first symbol it finds and then routes all the rest to it. (that's the purpose of inline)

[oiaohm]

You linked the same thing I did, so idk what you are talking about. If you mean the "binary" mode then of course it's not linkable since it's the binary result. Static libraries are a single file (collection of .o files) and totally linkable. Like using those buzzwords?

DId you do what I said add/remove inline and notice there are changes.

The fact godbolt shows a main when you do binary mode shows you are not looking at a .o disassemble. You want to see what the linker is processing you need to disassemble the .o or .obj. At this point you would start noticing the true effect of inline.

godbolt does not disasmble an object file showing the object global table. The object global table is what the modern linkers processes.

The .global "declare" is a fucking assembler-specific (GAS only) directive to tell it to export the symbol name in the object file. WTF are you even saying? It doesn't "exist" in the object file any more than a piece of source code exists there (it doesn't), it's an assembler directive and has nothing to do with any of this.

Sorry .global there is a masm equal that is called simple global just no full stop.

An inline function is shared in the linked output, it's only duplicated in each object file (if it is not inlined by the compiler, as the example I gave above). The linker then picks just one and discards the rest.

This is not what happens. Linkers optimisations are not super bright. Current day linkers don't automatically discard the rest reason for LTO.

Linkers that are not using LTO only optimise based on global declared functions this is a really simple optimisation if global declared function is used include if global function is not used don't include. This is not a gcc/binutils only this is fairly much all complier suites for the past 20 years have had linkers this dumb.

So you inline a function per object you end up with a copy of that function per object in the final binary unless you use LTO mode. This is one of the reasons why LTO mode can make executable way smaller is because this in fact does merge the duplicates of inlines.

.global gas and global in masm and others like it are a linker directive most people are not aware of because mostly you don't use them. The compiler is placing them or removing them..

godbolt.org shows you the debugging symbols not the linker symbols/table. The linker symbols are like the extern and global.. Inline is global missing. Inline is not a linker directive it is a anti-linker directive. This anti-linker directive has effects.

Basically there are a lot of stories told about linker optimisations like the idea that a linker will reduce a function to only 1 copy the reality linkers have not done that for over 2 decades. Lot of programs coded expected this we have only had functions reduced to 1 copy since the introduction of LTO that is return to compiler from linker..

[Weasel]

DId you do what I said add/remove inline and notice there are changes.

But there are no changes. Show a screenshot cause I'm not seeing any changes.

The fact godbolt shows a main when you do binary mode shows you are not looking at a .o disassemble.

That's the point. You don't use binary mode if you want to look at the assembly file (that ends up into .o). Stop grasping for straws.

godbolt does not disasmble an object file showing the object global table.

I don't care about the object file. All that matters is that the function is NOT INLINED and yet it is marked inline and it is duplicated in each object file, because that's the source assembly for the object file.

The inline keyword is still there, and its semantics are still there. The inlining decisions are arbitrary and based on compiler, and have nothing to do with the inline keyword's semantics as specified in the standard.

Sorry .global there is a masm equal that is called simple global just no full stop.

So?!? It's literally a directive for the assembler, a command to tell it what to do (i.e. export those symbols).

This is not what happens. Linkers optimisations are not super bright. Current day linkers don't automatically discard the rest reason for LTO.

They have to discard because they have the same symbols. It's just logic. It has nothing to do with LTO (which removes unused functions and such, nothing to do with symbols).

Without inline you violate The One Definition Rule.

Oh wait I forgot you don't even know what symbols actually are.

Note how Wikipedia even says:

• Some things, like types, templates, and extern inline functions, can be defined in more than one translation unit.

[oiaohm]

Note how Wikipedia even says:

• Some things, like types, templates, and extern inline functions, can be defined in more than one translation unit.

Re read that wikipedia again.
non-inline function cannot have more than one definition;<< Inline functions have more 1 define.

Yes defined differently in every translation unit in fact.

NO. The compiler may EXPORT THE FUNCTION and mark it inline so the linker knows to discard all of them except for one.

This is what you said Weasel. The fact that inlines named the same in different translation units(objects) can be different code means linkers don't discard to them at all. It would slow down linking to in fact handle this case linker were made for general performance not odd case handling. The compiler reduces inline to 1 or many per object file. The linker does nothing to inlines.

This is not the case. The modern linker is what enforces the one definition rule. If you have 2 definitions for non-inline functions the linker will error because it will be in the exported table of objects more than once. If a function is inline linker does not process it.

Its like the virtual method table example. Most linker don't in fact process the virtual method table instead just join the virtual method tables together so first entry wins.
g++ odr1.o odr2.o main.o
gives
odr ONE dummy: Hello
odr ONE dummy: Hello
g++ odr2.o odr1.o main.o
odr TWO dummy: World
odr TWO dummy: World

This is because linker. Linker does bugger all processing. Early C++ linker would have in fact resolved this giving the expected.
odr ONE dummy: Hello
odr TWO dummy: World

This is something -flto does not fix or detect.

-flto with gcc will detect that 2 inline functions in two different .o files are in fact the same function and merge them when they make sense. Other wise binutils ld will blindly put how many copies of inline functions in final binary. MSVC linker is the same. Linkers have almost intelligence these days. They fairly much just do conflict detection.

[Weasel]

Re read that wikipedia again.
non-inline function cannot have more than one definition;<< Inline functions have more 1 define.

Yes defined differently in every translation unit in fact.

...so? That's EXACTLY WHAT I SAID.

inline function -> it's defined in multiple object files (translation units).

Linker then picks 1 and discards the rest.

WTF are you even saying at this point?

This is what you said Weasel. The fact that inlines named the same in different translation units(objects) can be different code means linkers don't discard to them at all. It would slow down linking to in fact handle this case linker were made for general performance not odd case handling. The compiler reduces inline to 1 or many per object file. The linker does nothing to inlines.

WRONG. What I said was perfectly on point: the compiler, which compiles ONLY ONE object file, will export it if it's not inlined (i.e. in the example I gave).

It is REQUIRED for all inline definitions to be IDENTICAL or you violate the One-Definition Rule. So your bullshit of "different code" is just fantasy and a violation of the standard.

Of course, all of this is found in the wikipedia article, so you should follow your own advice and "re-read that wikipedia again".

From the same fucking phrase I quoted before:

• Some things, like types, templates, and extern inline functions, can be defined in more than one translation unit. For a given entity, each definition must be the same. Non-extern objects and functions in different translation units are different entities, even if their names and types are the same.

This is not the case. The modern linker is what enforces the one definition rule. If you have 2 definitions for non-inline functions the linker will error because it will be in the exported table of objects more than once. If a function is inline linker does not process it.

The One-Definition Rule is a language construct and in the case of inline it obviously "processes" it since it cannot compile with same symbol, has to discard all but one.

Virtual Method has nothing to do with it because it's not symbols.

[oiaohm]

...so? That's EXACTLY WHAT I SAID.

inline function -> it's defined in multiple object files (translation units).

Linker then picks 1 and discards the rest.

The reality linker does not do this.

test1.cpp

include <stdio.h>

inline void woof1(){
printf("hi1");
}

void test1(){
woof1();
}

test2.cpp

include <stdio.h>
inline void woof1(){
printf("hi2");
}
void test2(){
woof1();
}

main.cpp

extern void test1();
extern void test2();
int main (int argc, char **argv)
{
   test1();
   test2();

}

Build all that gcc or g++ or msvc.

Yes you will see behavour like odr where woof1 is magically coming the same function at runtime. But when you hexedit the binary and search for hi1 and hi2 no matter the optimisation both strings are still in the final binary and if you dig deeper the two different asm forms of woof1 are still in the final binary in a lot of cases. Basically zombie code because the linker is not doing what you think it is.

The modern linkers is not smart enough to discard the duplicate even if they are absolutely identical. As your program gets more complex and you use more and more inlines you can end up with increase amounts of this zombie code in your final binaries.

There is one thing in what the standard says. But there is a very different thing happening when you in fact check what the compilers and linkers are upto.

Better would not be makes the duplicates ignored that they exist but nicely fails to remove them.

The reality here compilers are able to obey the ODR rules while also making a complete mess of the final binary.