Question about ctors, dtors and sections on Windows

Hello all!

I extended the LDC2 with a pragma to register a funcion in the llvm.global_ctors or llvm.global_dtors list.

On Linux, references to these functions are placed in .ctors and .dtors sections and everything runs fine.

On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU, which is automatically called by the MS C Runtime. However, functions from llvm.global_dtors are placed in section .dtors which is unknown to the runtime. Therefore only ctors are called. Is this expected behaviour?

My expectation was that the dtors placed in .CRT$XTU which are the C terminator functions. Maybe there is a way to customize this?

Another question is how can I control section names and attributes.
Before I found the ctors/dtors variables I tried to implement this functionality by placing a variable in a section with a special name. This works because a global variable can have an optional section name.

But:
- How can I control section attributes and alingment? E.g. the .CRT$XU segment is read-only. How can I specify that?
- How can I place constant data in the .rdata section?

Thanks for any hints!

Regards
Kai

Hello

On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU,
which is automatically called by the MS C Runtime.

Only if you link with MS runtime. Mingw follows standard .ctors / .dtors scheme.

My expectation was that the dtors placed in .CRT$XTU which are the C
terminator functions. Maybe there is a way to customize this?

Yes. Target (or,rather subtarget) specifies this. Looks like it was
somehow missed for dtors.

- How can I control section attributes and alingment? E.g. the .CRT$XU
segment is read-only. How can I specify that?

This is job of target, not user code. If you need such granularity -
write assembler

- How can I place constant data in the .rdata section?

The global should be constant. Everything should happen automagically.
It might be some stuff which depends on relocations, etc.

Hello

On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU,
which is automatically called by the MS C Runtime.

Only if you link with MS runtime. Mingw follows standard .ctors / .dtors scheme.

Yes, I am targeting the MS runtime

My expectation was that the dtors placed in .CRT$XTU which are the C
terminator functions. Maybe there is a way to customize this?

Yes. Target (or,rather subtarget) specifies this. Looks like it was
somehow missed for dtors.

Thanks for the hint. I found it. I'll prepare a patch if I can fix it.

- How can I control section attributes and alingment? E.g. the .CRT$XU
segment is read-only. How can I specify that?

This is job of target, not user code. If you need such granularity -
write assembler

I am thinking about how to implement #pragma (init_seg) and #pragma(data_seg) from MSVC in the LDC compiler. Therefore I would need this control.

- How can I place constant data in the .rdata section?

The global should be constant. Everything should happen automagically.
It might be some stuff which depends on relocations, etc.

Seems to be another problem. I'll investigate this a bit more.

Thanks for your answers.

Kai

Hi Kai. I submitted the patch to use the .CRT$XCU section for ctors on
Win32; I did not do so for dtors because I was unaware of .CRT$XTU. My
apologies. If you look in lib/MC/MCObjectFileInfo.cpp:417, you can see
the following logic:


  if (T.getOS() == Triple::Win32) {
    StaticCtorSection =
      Ctx->getCOFFSection(".CRT$XCU",
                          COFF::IMAGE_SCN_CNT_INITIALIZED_DATA |
                          COFF::IMAGE_SCN_MEM_READ,
                          SectionKind::getReadOnly());
  } else {
    StaticCtorSection =
      Ctx->getCOFFSection(".ctors",
                          COFF::IMAGE_SCN_CNT_INITIALIZED_DATA |
                          COFF::IMAGE_SCN_MEM_READ |
                          COFF::IMAGE_SCN_MEM_WRITE,
                          SectionKind::getDataRel());
  }

The logic just needs to be replicated to set StaticDtorSection
appropriately for Win32 targets. Sorry again for the oversight.

-Joe