Start back at the basics, look at the object file dump, is ModuleInfo being generated?

If not, have you copied ModuleInfo over?

On Fri, Feb 16, 2024 at 02:28:25PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> Start back at the basics, look at the object file dump, is ModuleInfo being generated?

It's missing from the object file.


> If not, have you copied ModuleInfo over?

Does it need to be defined in object.d?


T

-- 
Doctor: "Sir, I’m afraid your DNA is backwards." / Patient: "And?"

On 16/02/2024 2:57 PM, H. S. Teoh wrote:
> On Fri, Feb 16, 2024 at 02:28:25PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
>> Start back at the basics, look at the object file dump, is ModuleInfo
>> being generated?
> 
> It's missing from the object file.
> 
> 
>> If not, have you copied ModuleInfo over?
> 
> Does it need to be defined in object.d?
> 
> 
> T

Yes.

https://github.com/dlang/dmd/blob/a952831fdb2877199c8eda07292757a0c5c29a1a/compiler/src/dmd/dmsc.d#L82

On Fri, Feb 16, 2024 at 03:08:06PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> On 16/02/2024 2:57 PM, H. S. Teoh wrote:
> > On Fri, Feb 16, 2024 at 02:28:25PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> > > Start back at the basics, look at the object file dump, is ModuleInfo being generated?
> > 
> > It's missing from the object file.
> > 
> > 
> > > If not, have you copied ModuleInfo over?
> > 
> > Does it need to be defined in object.d?
[...]
> Yes.
> 
> https://github.com/dlang/dmd/blob/a952831fdb2877199c8eda07292757a0c5c29a1a/compiler/src/dmd/dmsc.d#L82

Figures!  I was under the wrong impression that I only need to define it for code that actually needs to traverse it.  Thanks for the tip!!

I copy-n-pasted ModuleInfo from the real (non-wasm) object.d, and now I'm finally getting an address for __start___minfo.  However, __end___minfo for some reason still shows up as 0x0?  I must be missing something else?


T

-- 
Famous last words: I *think* this will work...

On 16/02/2024 5:45 PM, H. S. Teoh wrote:
> On Fri, Feb 16, 2024 at 03:08:06PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
>> On 16/02/2024 2:57 PM, H. S. Teoh wrote:
>>> On Fri, Feb 16, 2024 at 02:28:25PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
>>>> Start back at the basics, look at the object file dump, is
>>>> ModuleInfo being generated?
>>>
>>> It's missing from the object file.
>>>
>>>
>>>> If not, have you copied ModuleInfo over?
>>>
>>> Does it need to be defined in object.d?
> [...]
>> Yes.
>>
>> https://github.com/dlang/dmd/blob/a952831fdb2877199c8eda07292757a0c5c29a1a/compiler/src/dmd/dmsc.d#L82
> 
> Figures!  I was under the wrong impression that I only need to define it
> for code that actually needs to traverse it.  Thanks for the tip!!
> 
> I copy-n-pasted ModuleInfo from the real (non-wasm) object.d, and now
> I'm finally getting an address for __start___minfo.  However,
> __end___minfo for some reason still shows up as 0x0?  I must be missing
> something else?
> 
> 
> T

Great!

Unfortunately I don't know how the lists created by the linker work.

But I do know that they are linker specific.

On Fri, Feb 16, 2024 at 06:02:46PM +1300, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> 
> On 16/02/2024 5:45 PM, H. S. Teoh wrote:
[...]
> > I copy-n-pasted ModuleInfo from the real (non-wasm) object.d, and now I'm finally getting an address for __start___minfo.  However, __end___minfo for some reason still shows up as 0x0?  I must be missing something else?
[...]
> Great!
> 
> Unfortunately I don't know how the lists created by the linker work.
> 
> But I do know that they are linker specific.

Hmm, the module traversal code seems to depend on SectionGroup.  Does this need to be imported by object.d too?  Currently I only have it in a submodule in the runtime.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton

On 16/02/2024 6:02 PM, Richard (Rikki) Andrew Cattermole wrote:
> Great!
> 
> Unfortunately I don't know how the lists created by the linker work.
> 
> But I do know that they are linker specific.

I did some searching.

``__start_section`` and ``__stop_section`` are generated by the linker automatically for a given section.

https://stackoverflow.com/a/48550485

I have been able to replicate what it should be doing using run.dlang.io.

```d
import std;
import core.attribute;

void main()
{
    writeln([var1, var2, var3], __start_sect_test, __stop_sect_test);
}

__gshared extern(C) extern {
    immutable int* __start_sect_test;
    immutable int* __stop_sect_test;
}

__gshared {
    @(ldc.attributes.section("sect_test"))
    int var1 = 72;
    @(ldc.attributes.section("sect_test"))
    int var2 = 43;
    @(ldc.attributes.section("sect_test"))
    int var3 = 59;
}
```

Now you'll have something to compare the ``__minfo`` symbols to.

One thing to check is that your triple is for the binary wasm otherwise it might not be using sections.

https://github.com/ldc-developers/ldc/blob/6ede9a4fdfd04724fc28a60e6460993d8344136f/gen/modules.cpp#L105

https://github.com/llvm/llvm-project/issues/23280

https://reviews.llvm.org/D64148

This is consistently appearing to be related to GC'ing of sections.

I.e. try ``--no-gc-sections``.

Alternatively it may be better to swap over to the linked list approach, but you'll need to compile ldc to switch it over.