http://d.puremagic.com/issues/show_bug.cgi?id=5748

           Summary: @naked annotation
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2011-03-17 10:02:29 PDT ---
I think that the "naked" that currently is usable inside asm blocks is a property of the whole function that contains the asm block and not just of the asm block, so I suggest to deprecate (and later remove) the "naked" and to add a @naked function annotation.

An example, from (from dmd\src\druntime\src\core\thread.d):


version( D_InlineAsm_X86 ) {
    static void* getBasePtr() {
        asm {
            naked;
            mov EAX, EBP;
            ret;
        }
    }

    obj.m_main.bstack = getBasePtr();
} else version( D_InlineAsm_X86_64 ) {
    static void* getBasePtr() {
        asm {
            naked;
            mov RAX, RBP;
            ret;
        }
    }

    obj.m_main.bstack = getBasePtr();
}


To:

version( D_InlineAsm_X86 ) {
    @naked static void* getBasePtr() {
        asm {
            mov EAX, EBP;
            ret;
        }
    }

    obj.m_main.bstack = getBasePtr();
} else version( D_InlineAsm_X86_64 ) {
    @naked static void* getBasePtr() {
        asm {
            mov RAX, RBP;
            ret;
        }
    }

    obj.m_main.bstack = getBasePtr();
}

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

http://d.puremagic.com/issues/show_bug.cgi?id=5748


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |WONTFIX


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2011-03-17 11:21:28 PDT ---
naked is not a property of the function's interface, and therefore should properly not be part of its declaration.

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

http://d.puremagic.com/issues/show_bug.cgi?id=5748


Max Samukha <samukha@voliacable.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |samukha@voliacable.com


--- Comment #2 from Max Samukha <samukha@voliacable.com> 2011-03-17 15:47:07 PDT ---
Should an attribute be necessarily part of function interface? MSVC uses
__declspec(naked), which is not part of the function interface
(http://msdn.microsoft.com/en-us/library/h5w10wxs%28v=vs.80%29.aspx). Also, the
GNU compiler uses __attribute__((naked)). Having "naked" in the assembly block
has never felt right, really.

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

http://d.puremagic.com/issues/show_bug.cgi?id=5748



--- Comment #3 from Walter Bright <bugzilla@digitalmars.com> 2011-03-17 16:04:04 PDT ---
(In reply to comment #2)
> Should an attribute be necessarily part of function interface? MSVC uses
> __declspec(naked), which is not part of the function interface
> (http://msdn.microsoft.com/en-us/library/h5w10wxs%28v=vs.80%29.aspx). Also, the
> GNU compiler uses __attribute__((naked)). Having "naked" in the assembly block
> has never felt right, really.

Naked is an internal characteristic of a function, not an external one. It simply does not belong in the declaration, despite the existence of poorly designed extensions in other languages.

Think of it this way - is it a good design to have to change your header files if you change your implementation?

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

http://d.puremagic.com/issues/show_bug.cgi?id=5748



--- Comment #4 from Max Samukha <samukha@voliacable.com> 2011-03-18 00:24:35 PDT ---
(In reply to comment #0)
> I think that the "naked" that currently is usable inside asm blocks is a property of the whole function that contains the asm block and not just of the asm block, so I suggest to deprecate (and later remove) the "naked" and to add a @naked function annotation.
> 
> An example, from (from dmd\src\druntime\src\core\thread.d):
> 
> 
> version( D_InlineAsm_X86 ) {
>     static void* getBasePtr() {
>         asm {
>             naked;
>             mov EAX, EBP;
>             ret;
>         }
>     }
> 
>     obj.m_main.bstack = getBasePtr();
> } else version( D_InlineAsm_X86_64 ) {
>     static void* getBasePtr() {
>         asm {
>             naked;
>             mov RAX, RBP;
>             ret;
>         }
>     }
> 
>     obj.m_main.bstack = getBasePtr();
> }
> 
> 
> To:
> 
> version( D_InlineAsm_X86 ) {
>     @naked static void* getBasePtr() {
>         asm {
>             mov EAX, EBP;
>             ret;
>         }
>     }
> 
>     obj.m_main.bstack = getBasePtr();
> } else version( D_InlineAsm_X86_64 ) {
>     @naked static void* getBasePtr() {
>         asm {
>             mov RAX, RBP;
>             ret;
>         }
>     }
> 
>     obj.m_main.bstack = getBasePtr();
> }

(In reply to comment #3)
> (In reply to comment #2)
> > Should an attribute be necessarily part of function interface? MSVC uses
> > __declspec(naked), which is not part of the function interface
> > (http://msdn.microsoft.com/en-us/library/h5w10wxs%28v=vs.80%29.aspx). Also, the
> > GNU compiler uses __attribute__((naked)). Having "naked" in the assembly block
> > has never felt right, really.
> 
> Naked is an internal characteristic of a function, not an external one. It simply does not belong in the declaration, despite the existence of poorly designed extensions in other languages.
> 

But it is still a function characteristic and it definitely doesn't belong in the assembly block, so I think "poorly designed" applies to D as well.

> Think of it this way - is it a good design to have to change your header files if you change your implementation?

You do not need to change header files with MSVC because the attribute is permitted only in the function definition.

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

http://d.puremagic.com/issues/show_bug.cgi?id=5748



--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2011-03-18 01:04:49 PDT ---
(In reply to comment #4)
> > Naked is an internal characteristic of a function, not an external one. It simply does not belong in the declaration, despite the existence of poorly designed extensions in other languages.
> > 
> But it is still a function characteristic

Internal only. It is not externally visible and simply does not logically belong in the description of the external interface.

> and it definitely doesn't belong in
> the assembly block, so I think "poorly designed" applies to D as well.

Naked only makes sense if you have inline assembly, so physically associating it with that makes sense. There is no obvious syntax for it, but putting it in the function's external interface is just wrong.

> > Think of it this way - is it a good design to have to change your header files if you change your implementation?
> You do not need to change header files with MSVC because the attribute is permitted only in the function definition.

Sorry, but major yuk to that :-)

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

http://d.puremagic.com/issues/show_bug.cgi?id=5748



--- Comment #6 from Max Samukha <samukha@voliacable.com> 2011-03-18 01:55:04 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > > Naked is an internal characteristic of a function, not an external one. It simply does not belong in the declaration, despite the existence of poorly designed extensions in other languages.
> > > 
> > But it is still a function characteristic
> 
> Internal only. It is not externally visible and simply does not logically belong in the description of the external interface.
> 
> > and it definitely doesn't belong in
> > the assembly block, so I think "poorly designed" applies to D as well.
> 
> Naked only makes sense if you have inline assembly, so physically associating it with that makes sense. There is no obvious syntax for it, but putting it in the function's external interface is just wrong.

Only if you think about function attributes as attributes of the function's interface.

> 
> > > Think of it this way - is it a good design to have to change your header files if you change your implementation?
> > You do not need to change header files with MSVC because the attribute is permitted only in the function definition.
> 
> Sorry, but major yuk to that :-)

Maybe, you are right. Minor issue, anyway. Doesn't deserve a major yuk.

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

http://d.puremagic.com/issues/show_bug.cgi?id=5748


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #7 from Don <clugdbug@yahoo.com.au> 2011-03-18 07:27:29 PDT ---
Somewhat related is the Pervert Bug: (bug 2350).
Really, the compiler should be a lot stricter on what it allows inside a naked
function. IMHO, the main reason people feel that there's a need for annotation,
is that DMD currently allows a lot of garbage to compile. If the compiler were
adequately strict, it'd be clear it was an asm-only issue.

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