On Friday, 14 March 2014 at 08:56:25 UTC, Steve Teale wrote:
> On Friday, 14 March 2014 at 08:15:00 UTC, Mathias LANG wrote:
>> ./main
>> plugin ctor
>> I am plugin
>> I am plugin
>> I am plugin
>>
>>
>> Same result with master branch. Long story short: I can't reproduce it on my machine (Debian x86_64). Which platform are you working on ? 32 bits ?
>
> Ubuntu 12.04 32 bit.
>
> I'll reboot into 64 bit and try there.

Sure enough, works OK on 12.04 64 bit, so I guess it's a bug. Probably not core.runtime, because I think the problem still occurs if I use dlopen() directly, so code generation?

I'll work up a minimal test case just using an interface, then submit it, yes?

Steve

On Friday, 14 March 2014 at 09:08:17 UTC, Steve Teale wrote:
>
> I'll work up a minimal test case just using an interface, then submit it, yes?
>
There's an equivalent in the system already - issue 10719, but that does not mention the fact that the problem is 32 bit specific.

I updated it. Will install 2.065 and test with that.

On 2014-03-14 00:44, Sean Kelly wrote:

> It might be purely a matter of historic interest at this point,
> but DDL was basically doing plugins in D ages ago:
>
> http://www.dsource.org/projects/ddl

Yes, but DDL uses a custom linker.

> I /think/ this was the dynamic loading scheme h3r3tic used in his
> game engine back in the day.  I'm sure someone with a better
> memory than me could explain it better.

Yes, exactly. It basically allowed him to update code on the fly, when the application was running. He showed this on the Tango conference.

-- 
/Jacob Carlborg

On Friday, 14 March 2014 at 07:22:06 UTC, Mathias LANG wrote:
> On Thursday, 13 March 2014 at 13:22:55 UTC, Steve Teale wrote:
>> Does anyone have any suggestions as to what might be going wrong here? I have further examples, but I guess I should do them one at a time.
>>
>> Steve
>
> Copied your files, added: -L-rpath=/home/geod/bin/dmd-master/linux/lib64/
> as dmd is not on the system path for me.
>
> It was working. So try to update your compiler and check if that's the reason.

Everything works OK with 64 bit anyway!

On 03/14/2014 12:44 AM, Sean Kelly wrote:
>
> It might be purely a matter of historic interest at this point,
> but DDL was basically doing plugins in D ages ago:
>
> http://www.dsource.org/projects/ddl
>
> I /think/ this was the dynamic loading scheme h3r3tic used in his
> game engine back in the day.  I'm sure someone with a better
> memory than me could explain it better.

But this use object with non-PIC and does full relocation while loading.
Thus it also requires writable, executable memory which isn't available on many systems due to security issues.

On 03/13/2014 02:22 PM, Steve Teale wrote:
>
> main : ifd.d main.d
>      dmd -c ifd.d
>      dmd -c main.d
>      dmd main.o ifd.o -L-ldl -defaultlib=libphobos2.so -L-rpath=.
>
> plugin : plugin.d
>      dmd -c -shared -fPIC plugin.d
>      dmd plugin.o -shared -defaultlib=libphobos2.so -map
>
> clean :
>      rm *.o
>      rm main
>      rm plugin.so

One problem here is that main and the plugin share the definitions in ifd.d. Therefor you need to move the interface into it's own shared library and link both (main and any plugin) against the interface definition.

main : main.d ifd
     dmd -c main.d
     dmd main.o -L-ldl -defaultlib=libphobos2.so -L-rpath=. -L./ifd.so

plugin : plugin.d ifd
     dmd -c -shared -fPIC plugin.d
     dmd plugin.o -shared -defaultlib=libphobos2.so -L./ifd.so

ifd : ifd.d
     dmd -c -shared -fPIC ifd.d
     dmd ifd.o -shared -defaultlib=libphobos2.so

clean :
     rm *.o
     rm main ifd.so plugin.so

Note that it was possible to load plugin.so even though it has undefined symbols because we link with -L--export-symbols (for backtrace symbols). This linker flag causes the main executable to export it's symbols, so the plugin will resolve it's undefined symbols by using the ones from main. I'm still investigating why it crashes when using --export-dynamic though.

On 03/15/2014 09:50 PM, Martin Nowak wrote:
> I'm still investigating why it crashes when using --export-dynamic though.

Looks like a revenant of https://d.puremagic.com/issues/show_bug.cgi?id=9729.
The problem is that nobody sets ebx before calling the interface thunk, therefor resolving the @PLT entry fails.

_TMP5   LABEL NEAR
        sub     eax, 8                                  ; 0078 _ 83. E8, 08
        jmp     _D6plugin6Plugin12saySomethingMFZAya    ; 007B _ E9, FFFFFFFC(PLT r)

On 03/15/2014 11:04 PM, Martin Nowak wrote:
> On 03/15/2014 09:50 PM, Martin Nowak wrote:
>> I'm still investigating why it crashes when using --export-dynamic
>> though.
>
> Looks like a revenant of
> https://d.puremagic.com/issues/show_bug.cgi?id=9729.
> The problem is that nobody sets ebx before calling the interface thunk,
> therefor resolving the @PLT entry fails.
>
> _TMP5   LABEL NEAR
>          sub     eax, 8                                  ; 0078 _ 83.
> E8, 08
>          jmp     _D6plugin6Plugin12saySomethingMFZAya    ; 007B _ E9,
> FFFFFFFC(PLT r)
>

I prepared a fix here (https://github.com/MartinNowak/dmd/tree/thunkEBX)
but it needs more work. Currently it violates the platform ABI because the interface thunk destroys EBX.

On Saturday, 15 March 2014 at 22:56:19 UTC, Martin Nowak wrote:
> On 03/15/2014 11:04 PM, Martin Nowak wrote:
>> On 03/15/2014 09:50 PM, Martin Nowak wrote:
>>> I'm still investigating why it crashes when using --export-dynamic
>>> though.
>>
>> Looks like a revenant of
>> https://d.puremagic.com/issues/show_bug.cgi?id=9729.
>> The problem is that nobody sets ebx before calling the interface thunk,
>> therefor resolving the @PLT entry fails.
>>
>> _TMP5   LABEL NEAR
>>         sub     eax, 8                                  ; 0078 _ 83.
>> E8, 08
>>         jmp     _D6plugin6Plugin12saySomethingMFZAya    ; 007B _ E9,
>> FFFFFFFC(PLT r)
>>
>
> I prepared a fix here (https://github.com/MartinNowak/dmd/tree/thunkEBX)
> but it needs more work. Currently it violates the platform ABI because the interface thunk destroys EBX.

Thanks Martin - it's good to have you involved. I'd got as far as dissasembling it and stepping single instructions in GDB while looking at that, so I could have told you where it crashed, but had no idea what was going on

On Saturday, 15 March 2014 at 22:56:19 UTC, Martin Nowak wrote:
> On 03/15/2014 11:04 PM, Martin Nowak wrote:
>> On 03/15/2014 09:50 PM, Martin Nowak wrote:
>>> I'm still investigating why it crashes when using --export-dynamic
>>> though.
>>
When you've fixed this, you should also be able to mark issue 10719 as fixed ;=)