WRONG 3.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172
  1. This file contains a summary of the bugs/features/inconsistencies
  2. Robbert and Ed found while making the linker usable for the 68000 and amoeba.
  3. There is something wrong with the way the combination of
  4. assembler and linker handle bss.
  5. In the original (Duk's) the assembler translated .space and, worse, .align
  6. to a sequence of zero's. If this sequence was at the end of a segment
  7. within a module the assembler didn't put zero in the segment but sets
  8. os_flen to the amount of space initialized before the zero space
  9. and os_size to the segements size. (os_size - os_flen) is then the
  10. size of the space filled by zeroes.
  11. For the sake of clarity, let us call 0...os_flen-1 initialized space
  12. and os_flen..os_size-1 uninitialized space.
  13. Now the linker, it does a nasty trick. It gathers the uninitialized space
  14. of all modules within a segment and puts it consequtively at the end
  15. of the segment. I think that I understand the reason: This way you can keep
  16. your resultant a.out smaller and you don't need a special bss segment
  17. (a la unix). But it is incorrect, the net effect is that the .align's
  18. at the end of segments within a module do have the desired effect,
  19. the space thus allocated is removed to 'higher spheres' thereby
  20. leaving the first items of that segment in the inmediatly following
  21. modules at unaligned boundaries.
  22. What should be done is that the linker leaves the initialized and
  23. the unitialized code alone and regards the whole a a chunk that can be
  24. relocated. Only producing a difference of os_size and os_flen for
  25. the zeroes at the very end of the segment. Thereby collapsing all
  26. .space (and .align) commands into zero space only if they
  27. are in consequtive modules at the end of the segment, with modules
  28. NOT containing any initialized data.
  29. I already, ad-hoc, changed the code of the assembler to producing 'hard'
  30. zeroes when aligning. The trick could also be done for .space
  31. but is a bit harder here.
  32. The reason: .space is also used to allocate space in the BSS segment
  33. if that produced zeroes in the a.out file (0..bss_size) we would
  34. have a.out files that are far too large.
  35. This feature of the linker also caused weird effects for names that
  36. are defined as the very last in a section within a module, without
  37. any data (initialized or uninitialezed) after it.
  38. The names a regarded as pointing into the uninitialized space and
  39. thus relocated to the end of the section.
  40. The sequence
  41. .sect .data
  42. begdata:
  43. .sect ....
  44. in an head_em.s resulted in the relocation of begdata to the END
  45. of the .data segment.
  46. Another problem form the commons:
  47. 1 - Local commons are not handled by led and not produced by as.
  48. using .comm for unitialized data is not correct because (from C)
  49. two uninitialized static declarations for the same name in
  50. different modules will be handled as external commons and thus
  51. be overlayed.
  52. 2 - The commons are allocated at the very end of the first pass, after the
  53. initialezed data has been allocated in the segments. The order on which
  54. the commons are allocated seems to be random. That way it is impossible
  55. to produce a label that is guaranteed to point to the last byte (+1)
  56. of a segment containing commons.
  57. The currently used trick is to declare an extra segment after the
  58. segment containing the commons. The first bytre in this segment
  59. inmediatly follows the commons and can be used as _end or endbss.
  60. The archiver (aal) with the automatic ranlib is buggy.
  61. The only thing that seems to work at the moment is creation of a fresh
  62. archive.
  63. replacing/adding/deleting modules is likely to produce libraries
  64. with incorrect ranlib entries.
  65. The major troublemaker seems to be the extra padding byte at the end
  66. of odd sized modules.
  67. Led should return a non-zero value when it has found Undefined symbols
  68. or has another reason for not being able to produce a correct output file.