Subversion Repositories QNX 8.QNX8 linker driver

Rev

Rev 9 | Go to most recent revision | Show entire file | Ignore whitespace | Details | Blame | Last modification | View Log | RSS feed

Rev 9 Rev 14
Line 1... Line 1...
1
QNX 8.0 'gcc' linker driver drop-in replacement by Pierre-Marie Baty
1
# QNX 8.0 `gcc` linker driver drop-in replacement
2
 
2
 
3
RATIONALE
3
```
4
=========
4
# uname -a
-
 
5
QNX XPS64-df54 8.0.0 2024/06/13-12:41:48EDT x86pc x86_64
5
 
6
 
6
Until a proper QNXToolchain class is implemented in the Clang driver, Clang
-
 
7
relies on GNU GCC to drive the system linker when it hasn't enough knowledge
-
 
8
of the underlying platform. So, if we are to provide a LLVM/Clang-based native
-
 
9
toolchain for QNX, we *HAVE* to provide a 'gcc' executable for Clang to be
-
 
10
able to link QNX files. This is an either/or situation and it was decided
-
 
11
that reimplementing an external linker driver would be faster than doing it
-
 
12
in the LLVM codebase (mostly because of the very long iteration times that
-
 
13
rebuilding LLVM causes, even when using a compiler cache.)
7
# gcc hello.c
14
 
8
 
15
Why does Clang chain-call gcc with the intent of linking ? Because GNU GCC is
-
 
16
itself a 'driver' which can also invoke either a compiler or a linker ('gcc'
-
 
17
invokes 'cc1' or 'cc1plus', the actual compiler, depending on the language, 
-
 
18
then runs 'collect2' which in turn invokes 'ld', the UNIX linker). This means
-
 
19
our drop-in GCC replacement will need to either chain-call 'clang' when it is
-
 
20
called with the intent of *compiling* and chain-call 'ld' when it is called
-
 
21
with the intent of *linking*. This can be decided by looking at its command-
-
 
22
line arguments.
9
# ./a.out
-
 
10
Hello world!
-
 
11
```
23
 
12
 
24
How will our drop-in gcc replacement know how to call 'ld' correctly ? Because
-
 
25
when proper support is added to it, GNU GCC contains a 'linker specification'
-
 
26
for the system (a string of symbols describing a sort of decision tree) which
-
 
27
it uses to construct the linker command line. The 'ld' linker specifications
-
 
28
for QNX 8.0 can be extracted from 'gcc -dumpspecs' from the cross-compilers
-
 
29
(Win64->QNX and Linux->QNX) provided by Blackberry and have been reimplemented
-
 
30
in this file.
-
 
31
 
13
 
-
 
14
## Rationale
-
 
15
 
-
 
16
Until a proper QNXToolchain class is implemented in the Clang driver, Clang relies on GNU GCC to drive the system linker when it hasn't enough knowledge of the underlying platform.
-
 
17
 
-
 
18
So, if we are to provide a LLVM/Clang-based native toolchain for QNX, we *HAVE* to provide a `gcc` executable for Clang to be able to link QNX files.
-
 
19
 
32
The GNU specs language is documented here:
20
This is an either/or situation and it was decided that reimplementing an external linker driver would be faster than doing it in the LLVM codebase (mostly because of the very long iteration times that rebuilding LLVM causes, even when using a compiler cache.)
-
 
21
 
-
 
22
### Why would Clang chain-call `gcc` with the intent of linking?
-
 
23
 
-
 
24
Because GNU GCC is itself a 'driver' which can also invoke either a compiler or a linker (`gcc` itself invokes `cc1` or `cc1plus`, the actual compiler, depending on the language, then runs `collect2` which in turn invokes `ld`, the UNIX linker).
-
 
25
 
-
 
26
This makes GCC the unique entrypoint for any platform- and target-specific compilation and linking task, and foreign compilers such as Clang just leverage that feature when support of the target system isn't built-in.
-
 
27
 
-
 
28
This implies a drop-in GCC replacement needs to either chain-call `clang` when it is called with the intent of *compiling* and chain-call `ld` when it is called with the intent of *linking*.
-
 
29
 
-
 
30
This can be decided by looking at its command-line arguments.
-
 
31
 
-
 
32
### How does this drop-in `gcc` replacement know how to call `ld` correctly?
-
 
33
 
-
 
34
Because when proper support is added to it, GNU GCC contains a 'linker specification' for the system (a string of symbols describing a sort of decision tree) which it uses to construct the linker command line.
-
 
35
 
-
 
36
The `ld` linker specifications for QNX 8.0 are public (because GCC is) and can be extracted from `gcc -dumpspecs` from the Win64->QNX and Linux->QNX cross-compilers provided by Blackberry, and have been reimplemented in this file.
-
 
37
 
33
https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
38
The GNU specs language is documented [on the GNU website here](https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html).
-
 
39
 
-
 
40
## Driver behaviour
34
 
41
 
35
The following environment variables control the behaviour of the driver:
42
The following environment variables control the behaviour of the driver:
-
 
43
 
36
   DEBUG_LINKER_DRIVER - when defined to any value (including an empty
44
- `DEBUG_LINKER_DRIVER` - when defined to any value (including an empty string), the constructed ld command line is printed to the standard error before calling the linker.
37
                         string), the constructed ld command line is printed
-
 
-
 
45
 
-
 
46
 
38
                         to the standard error before calling the linker.
47
## How to build
39
 
48
 
40
Build with:
49
Build with:
41
	qnxsdp_env
50
	qnxsdp_env
42
	ntox86_64-gcc linkerdriver.c -o gcc
51
	ntox86_64-gcc linkerdriver.c -o gcc
43
 
52
 
44
or just 'make' on Win32.
53
or just `make` on Win32.
45
 
54
 
46
-- 
55
-- 
47
Pierre-Marie Baty <pm@pmbaty.com>
56
Pierre-Marie Baty <pm@pmbaty.com>