Hi,
DATA and BSS segment of the library have to be directly after the TEXT segment, and the linker has to align the BSS and DATA segment onto amultiple of the MMU page size. The compiler also needs to know the pagesize to generate proper access to DATA and BSS segment. (Perhaps GCC does this already?)Even if an executable has only one translation table, you know the size of the TEXT segment, so you know if you are relocating an address in the TEXTor the DATA segment, so you can align the segments on MMU pages boundaries.
But this doesn't work if the compiler generates PC relativ addresses. E.g. "move.l data(PC), D0" can't work correctly if the assembler does not know the correct offset to generate. I must admit, I'm new to GCC. But Pure C makes extensive use of PC relativ addressing modes. (=> this gives smaller and faster code) In a dynamic library this can't work. I.e. you can't displace the DATA or BSS segment "as you like". The correct alignment of DATA and BSS segment relative to the TEXT segment has to be known at compile time.
An example:The compiler generates 200 bytes of code, 50 bytes of data (10 bytes in BSS and 40 bytes in DATA segment).
Case 1: Normally the segments are placed this way: Offset 0 - TEXT - Offset 200 - DATA - Offst 240 - BSS -But as we want to use the MMU, we have to align the segments on "memory page boundaries".
Case 2 (supposing page size of 2048 bytes): Offset 0 - TEXT - Offset 2048 - DATA - Offset 4092 - BSS -(OK, there is no real need to align the BSS on its own page. It's sufficient to align TEXT and DATA+BSS segments on page boundaries.)
If the compiler was thinking that the code will be executed in "case 1", he generates PC relative code which accesses DATA at offset 200 instead at 2048. => It's important that the compiler has knowledge of the memory alignment when the application is executed.
To avoid this problem you can simply forbidd the usage of PC relative addressing modes. IMO a bad solution!
Philipp