| Brian Silverman | 8649792 | 2018-02-10 19:28:39 -0500 | [diff] [blame^] | 1 | Fundamental design decision: |
| 2 | |
| 3 | - the sizes of external and internal types are assumed to be the same. |
| 4 | This leaves byte ordering aside. While assuming this the code can be |
| 5 | greatly simplified and speed increases. Since no change violating this |
| 6 | assumption is in sight this is believed to be a worthwhile optimization. |
| 7 | |
| 8 | - the ABI of the backend modules is not guaranteed. Really, no guarantee |
| 9 | whatsoever. We are enforcing this in the code. The modules and their |
| 10 | users must match. No third-party EBL module are supported or allowed. |
| 11 | The only reason there are separate modules is to not have the code for |
| 12 | all architectures in all the binaries. |
| 13 | |
| 14 | - although the public libraries (libasm, libdw) have a stable API and are |
| 15 | backwards ABI compatible they, and the elfutils tools, do depend on each |
| 16 | others internals, and on internals of libelf to provide their interfaces. |
| 17 | So they should always be upgraded in lockstep when packaging the tools |
| 18 | and libraries separately. For one example of how to do that, see the |
| 19 | config/elfutils.spec. |
| 20 | |
| 21 | Some notes: |
| 22 | |
| 23 | - old GNU ld's behavior wrt DSOs seems to be severely broken. |
| 24 | |
| 25 | y.o reference foo() |
| 26 | y1.o defines foo(), references bar() |
| 27 | y2.o defines bar() |
| 28 | libbar.so defines bar() |
| 29 | |
| 30 | Running |
| 31 | |
| 32 | gcc -o y y.o -lbar y1.o y2.o |
| 33 | |
| 34 | uses the bar() definition from libbar.so and does not mention the definition |
| 35 | in y2.o at all (no duplicate symbol message). Correct is to use the |
| 36 | definition in y2.o. |
| 37 | |
| 38 | |
| 39 | y.o reference foo() |
| 40 | y1.o defines foo(), references bar() |
| 41 | y2.o in liby2.a defines bar() |
| 42 | libbar.so defines bar() |
| 43 | |
| 44 | Running |
| 45 | |
| 46 | gcc -o y y.o -lbar y1.o -ly3 |
| 47 | |
| 48 | has to use the definition in -lbar and not pull the definition from liby3.a. |
| 49 | |
| 50 | |
| 51 | - the old linker follows DT_NEEDED entries and adds the objects referenced |
| 52 | this way which define a symbol which is needed as a DT_NEEDED to the |
| 53 | generated binary. This is wrong since the DT_NEEDED changes the search |
| 54 | path in the object (which is breadth first). |
| 55 | |
| 56 | |
| 57 | - the old linker supported extern "C++", extern "java" in version scripts. |
| 58 | I believe this implementation is severly broken and needs a redesign |
| 59 | (how do wildcards work with these languages*?). Therefore it is left |
| 60 | out for now. |
| 61 | |
| 62 | |
| 63 | - what should happen if two sections in different files with the same |
| 64 | name have different types and/or the flags are different |
| 65 | |
| 66 | |
| 67 | - section names in input files are mostly irrelevant. Exceptions: |
| 68 | |
| 69 | .comment/SHT_PROGBITS in strip, ld |
| 70 | |
| 71 | .debug \ |
| 72 | .line | |
| 73 | .debug_srcinfo | |
| 74 | .debug_sfnames | |
| 75 | .debug_aranges | |
| 76 | .debug_pubnames | |
| 77 | .debug_info | |
| 78 | .debug_abbrev | |
| 79 | .debug_line | |
| 80 | .debug_abbrev > DWARF sections in ld |
| 81 | .debug_line | |
| 82 | .debug_frame | |
| 83 | .debug_str | |
| 84 | .debug_loc | |
| 85 | .debug_macinfo | |
| 86 | .debug_weaknames | |
| 87 | .debug_funcnames | |
| 88 | .debug_typenames | |
| 89 | .debug_varnames / |
| 90 | |
| 91 | Sections created in output files follow the naming of special section |
| 92 | from the gABI. |
| 93 | |
| 94 | In no place is a section solely indentified by its name. Internal |
| 95 | references always use the section index. |