Re: Relocating section at virtual address 0

[Daniël Mantione <daniel at deadlock dot et dot tudelft dot nl>]

Op Tue, 26 Jul 2005, schreef Daniel Jacobowitz:

> I'm not sure if the linker can do what you are trying to make it do,
> but I'm absolutely sure that you shouldn't be accomplishing your goal
> this way.

Yes, I have meanwhile succeeded. The problem was that the compiler was
declaring variables with .comm, and variables declared with .comm always
get into the .bss section, even if declared into another section. Go
figure... I changed the compiler to output labels before .skip statements,
which worked a lot better.

> Do you have a reason not to use the same thread-local storage ABI that
> has already been implemented for C/C++?  If you use .tdata and .tbss,
> everything will just work.  You can even reuse glibc to handle all of
> the startup and relocation issues.

We're trying to design an interface that we can use across all platforms.
I'm sure Linux does things different than for example, Beos, and it is
definately the case that things are done differently again on the
Microsoft platform. (GCC/Linux tries do to something with gs:, Visual
C++/Win32 does something with fs:).

I have experimented with .tbss, but the GNU assembler tries to assign
section flags by default, which is all kind of magic I don't want to
happen, and I would also need to add that magic to the internal
assembler, so I think it is better to stay out of the GCC playground.

Using a C runtime library for a Pascal compiler is definately out of the
question; GNU Pascal did it, Kylix did it and they both failed. The reason
is that library maintainers simply don't give anything about Pascal users
and break compatibility whenever they don't like the weather. This is
especially true for glibc, which breaks even between minor revisions, but
we've bad experiences with other projects as well. Free Pascal has its
own portable runtime library.

It is the same with ABI's as well. One cannot implement required Pascal
language features like nested procedures, open strings/open arrays with
C/C++ ABI's. We support the real standardized standard calling conventions
like stdcall and cdecl to be able to interface with normal C code, but as
soon as you try to interface with object oriented C++ code for example,
you enter hell itself.

I have another question. I have now placed my .threadvar section
before.bss in the linker script.

  _threadvar_start = .;
  .threadvar 0 : AT (_threadvar_start) { *(.threadvar .threadvar.*) }
  PROVIDE (_threadvar_size = SIZEOF(.threadvar));
  . = _threadvar_start + SIZEOF (.threadvar);
  _threadvar_end = .;
  .bss            :
  {
   *(.dynbss)
   *(.bss .bss.* .gnu.linkonce.b.*)
   *(COMMON)
   /* Align here to ensure that the .bss section occupies space up to
      _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections.  */
   . = ALIGN(32 / 8);
  }

At the start of the linker script there is a use of the default
SIZEOF_HEADERS function:

  PROVIDE (__executable_start = 0x08048000); . = 0x08048000 + SIZEOF_HEADERS;

Now, the documentation warns that this construction is very fragile as the
linker's calculation of the program headers size if not very accurate. In
other words, this causes an error message if I add the section as now 3
program headers are needed, while the linker guesses 2. This is easy to
fix by replacing SIZEOF_HEADERS with a hard coded constant, but not nice.

Can I tweak the linker script so the linker guesses correct that it needs
to allocate 3 program headers?

Daniël Mantione