Hi Peng, On Fri, Apr 23, 2021 at 2:30 AM Xi Ruoyao via Gcc-help <gcc-help@xxxxxxxxxxx> wrote: > > This seems to be an incompletely mentioned list of architectures. What > > about other architectures? As mentioned in this thread, the upper and > > lower case options are no different on x86. But this can not be seen > > here. > > If you really care those architectures, read the psABI of them. psABI stands for "processor-specific application binary interface" and is important for linking, which can either be a static linking (i.e., linking multiple object files to obtain a single executable file and is usually done using the GNU Binutils's ld) or a dynamic linking (i.e., linking multiple shared library files (*.so) to execute a program read from an executable file and is usually done using the GNU C Library's ld.so). I think the importance of ABI is best illustrated when multiple programming languages are used to develop a single program (e.g., using Fortran for the scientific computation part, using C++ for the simulation part, and using Prelude, which is available at http://www.lifl.fr/~forget/prelude.html, for the control part). (FYI, I studied multilingual program development, which is better known as language-oriented programming (LOP); the report is available at https://doi.org/10.15168/11572_256168.) In this multilingual setting, the object files produced by the different compilers do not know each other at the API (i.e., source-code) level (e.g., Prelude knows neither Fortran nor C++). However, since the produced object codes agree on the same ABI, they can be linked together either statically (all of the object files are linked into one executable file) or dynamically (e.g., the C++ simulation object files are linked into a shared library while the Fortran and Prelude object files are linked into one executable file, which is then dynamically linked at runtime with the simulation shared library). To be more specific, an ABI specifies among other things how to make a routine/procedure/function call regardless of the source code. This specification is processor specific because among other things each processor has a different set of CPU registers which are affected in different ways by different instructions. For example, if a processor has only four 16-bit registers, then the psABI has to specify how a function call should return a datum whose size is greater than 64 bits (perhaps the psABI would specify that the datum shall be placed in memory and a pointer to the memory location shall be returned in register A). It is clear that the design of a psABI specification should aim for the efficiency of program execution as well as the stability of the specification itself (specifically, any future revision of the specification should not invalidate any of its previous version; this is better known as maintaining backward compatibility). As an aside, the multilingual programming setting is not the common case where ABI is critical. The more common case where ABI is critical is for the dynamic linking of every shared library that a program needs. The common case usually encounters a problem called a break/incompatibility in the ABI (i.e., an ABI break), which likely to happen when the different shared libraries are updated independently. This problem despite its naming does not mean that the psABI is updated without any backward compatibility left. Instead, it means that, for example, some function in some shared library has changed its interface by either changing the semantics (e.g., data type) or removing/adding some parameters. > > By "executable", it means whether it can be run or not? Many .so files > > (see below) do have the x permission. So the word "executable" is also > > ambiguous? > > > > $ ls -lgG /lib/x86_64-linux-gnu/libc-2.31.so > > -rwxr-xr-x 1 1839792 2021/01/05-00:47:42 /lib/x86_64-linux-gnu/libc- > > 2.31.so > > > > "To make a shared library executable you just need to give it a > > PT_INTERP segment and appropriate startup code." > > > > Although there is this explanation of executable afterward, it is > > again confusing. The following .so file also has .interp. I don't know > > what "startup code" specifically refers to. But it does have some > > startup code. However, I don't think the author means this file is an > > "executable". My understanding of "executable" is just something that > > can run. > > > > $ readelf -x .interp /lib/x86_64-linux-gnu/libc-2.31.so > > > > Hex dump of section '.interp': > > 0x00193f20 2f6c6962 36342f6c 642d6c69 6e75782d /lib64/ld-linux- > > 0x00193f30 7838362d 36342e73 6f2e3200 x86-64.so.2. > > > > $ objdump -d /lib/x86_64-linux-gnu/libc-2.31.so |grep start > > 26b97: 48 8b 05 a2 73 19 00 mov > > 0x1973a2(%rip),%rax # > > 1bdf40 <_dl_starting_up> > > 0000000000026c20 <__libc_start_main@@GLIBC_2.2.5>: > > 26c3a: 48 8b 15 ff 72 19 00 mov > > 0x1972ff(%rip),%rdx # > > 1bdf40 <_dl_starting_up> > > ... > > > > Do you see what is wrong with writeup like these? > > libc.so is just a special case. If you run it directly it will print > its version info. I don't know any other shared object with such a > "feature" (and this libc feature is never used by 99.99% of people, I > think). Just enter this command in your shell to see that the library is executable: $ /lib/x86_64-linux-gnu/libc-2.31.so -- Best regards, Tadeus
