www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11910] New: Writes to extern (C) struct have no effect

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910

           Summary: Writes to extern (C) struct have no effect
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Windows
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: turkeyman gmail.com



Is this bad codegen, or have I done something wrong?

extern (C) struct MFDefaults
{
    extern (C) struct InputDefaults
    {
        bool allowMultipleMice;
        bool mouseZeroIsSystemMouse;
        bool systemMouseUseWindowsCursor;
        bool useDirectInputKeyboard;
        bool useXInput;
    }

    InputDefaults input;
}

extern (C) __gshared MFDefaults gDefaults;

void f()
{
  gDefaults.input.useXInput = false; // assignment has no effect
}


This code builds and links successfully. In the debugger I can inspect the
values of the struct and they are correct, consistent with the struct in the C
code.
But when I assign to anything, it simply has no effect...

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 12 2014
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910


David Nadlinger <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code klickverbot.at



PST ---
I checked the generated code on Linux x86_64 and it seems fine (store immediate
zero in gDefaults at offset 4). So, more details and instructions to reproduce,
please. ;)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 12 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910




I'm building with DMD-Win64.

Digging further, I see this instruction in the debugger:
mov         byte ptr [gDefaults+9Ch (7F685FBF01Ch)],1

Which looks correct...
But note, the debugger helpfully shows the calculated store address:
7F685FBF01Ch
&gDefaults.input.useXInput == 7F685FEBC7Ch

It should write to ...FEBC7Ch, but instead it writes to ...FBF01Ch, which is
WAY before where it should be writing.

If I inspect the memory surrounding the address that it actually writes to, it
is filled with things like fully justified D symbols (with module name and
everything), path strings, lots of zeroes and float 1.0's. Not the structure I
expect to see.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 12 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910






 I'm building with DMD-Win64.
 
 Digging further, I see this instruction in the debugger:
 mov         byte ptr [gDefaults+9Ch (7F685FBF01Ch)],1


Note: +9C in mine is because my structure is actually much larger, I trimmed it
down to log the bug. The offset 9C looks right.

The debugger also illustrated 'gDefaults' as the store address, which I guess
means the address it writes to does match the symbol record in the debug info.
I guess the address emitted for gDefaults is wrong somehow?
But... that symbol should come from the external C library :/

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 12 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910


Jacob Carlborg <doob me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob me.com






 Note: +9C in mine is because my structure is actually much larger, I trimmed it
 down to log the bug. The offset 9C looks right.
 
 The debugger also illustrated 'gDefaults' as the store address, which I guess
 means the address it writes to does match the symbol record in the debug info.
 I guess the address emitted for gDefaults is wrong somehow?
 But... that symbol should come from the external C library :/


What is "gDefaults" supposed to be? A symbol from a C library? In that case you
forgot "extern", the correct declaration should be:

extern (C) extern __gshared MFDefaults gDefaults;

Have a look at: http://dlang.org/interfaceToC.html#C%20Globals

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910






 
 What is "gDefaults" supposed to be? A symbol from a C library?


Yes, I thought that was clear from the 'extern (C)'.


 In that case you forgot "extern", the correct declaration should be:
 
 extern (C) extern __gshared MFDefaults gDefaults;


Umm... I think you need to look at the OP again.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910






 In that case you forgot "extern", the correct declaration should be:
 
 extern (C) extern __gshared MFDefaults gDefaults;
 
 Have a look at: http://dlang.org/interfaceToC.html#C%20Globals


... oh
Crap, where's that edit button!

Wow, I have no words.
I never would have spotted that a mile off, even when you said it!

That seems extremely redundant :/

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910







 ... oh
 Crap, where's that edit button!
 
 Wow, I have no words.
 I never would have spotted that a mile off, even when you said it!
 
 That seems extremely redundant :/


If you don't specify "extern" you get the storage of the variable in the D
code.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910


Manu <turkeyman gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED





 If you don't specify "extern" you get the storage of the variable in the D
 code.


Right, but shouldn't I have gotten a multiply defined symbols link error in
that case?

* Marked resolved, user error! >_<

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910


Manu <turkeyman gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |INVALID


-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910







 Right, but shouldn't I have gotten a multiply defined symbols link error in
 that case?


I think in some cases it just overrides the C symbol. Not overrides, but
prefers the one in D. Walter has mentioned a couple of times this is possible.
It might be a Windows/Optlink only thing.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910







 

 Right, but shouldn't I have gotten a multiply defined symbols link error in
 that case?


 
 I think in some cases it just overrides the C symbol. Not overrides, but
 prefers the one in D. Walter has mentioned a couple of times this is possible.
 It might be a Windows/Optlink only thing.


I'm linking against C code, so I have to use Win64 and the MS linker, which I'm
very familiar with.
It may be that it just chose one, but curious to know why... anyway, all good.
I'll look into that more closely later on.
False alarm, thanks for spotting my mistake! >_<

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11910







 I'm linking against C code, so I have to use Win64 and the MS linker, which I'm
 very familiar with.
 It may be that it just chose one, but curious to know why... anyway, all good.


I found this on stackoverflow[1]:

"The linker will search the files you provide on the command line first for
symbols, before it searches in libraries"

[1] http://stackoverflow.com/a/19023148/1787929

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2014