[Bug 1001142] New: User defined linker sections.

[Bug 1001142] New: User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

           Summary: User defined linker sections.
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: Cortex-M
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ilijak@siva.com.mk
                CC: ecos-patches@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1116)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1116)
User defined linker section macro.

Submitted patch provides for user defined memory sections. This can be useful
with devices with fragmented memory.

Macro SECTION_user() has additional parameter _name_ that enables user to
define section name. Arbitrary number of sections can be defined.

Synopsys:
    SECTION_user(_name_, _region_,  _vma_, _lma_)
       _name_   - section name (without leading '.')
       _region_ - region in which to place the section
       _vma_    - virtual memory address
       _lma_    - load memory address

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1001114

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #1 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-13 17:39:42 GMT ---
I thought that's what. Another place where we could define SECTION_user
macro could be lpc17xx variant linker include file, e.g.

  cortexm/lpc17xx/var/current/include/pkgconf/mlt_cortexm_lpc17xx.ldi

This definition could be included from the target's memory layout
files.

- variant's source is a good place to comment what is macro for;

- no mess in architecture linker script, if that is a pain;

What do you think about such a compromise?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-13 18:47:32 GMT ---
(In reply to comment #1)

Sergei

There has been discussion on this in bug 1001114 where user sections were
introduced, and this bug is an outcome of that discussion. Please refer to bug
1001114 for a complete evolution.

> I thought that's what. Another place where we could define SECTION_user
> macro could be lpc17xx variant linker include file, e.g.
> 
>   cortexm/lpc17xx/var/current/include/pkgconf/mlt_cortexm_lpc17xx.ldi

You'll find an example snippet here:
http://bugs.ecos.sourceware.org/attachment.cgi?id=1088
and here's a description:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001114#c7 

> 
> This definition could be included from the target's memory layout
> files.
> 
> - variant's source is a good place to comment what is macro for;
> 
> - no mess in architecture linker script, if that is a pain;
> 
> What do you think about such a compromise?

It is a considerable step to add new feature to an architecture and should be
carried out with caution. Technically, the macro shall perform it's function at
either place, probably more relevant questions are following:


  - Shall we need this kind of facility for other future variants and how
often?
  - Is the macro (as is or with reasonable modifications) generic enough to
enter at architecture level?

I am open for any resolution.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-13 19:02:13 GMT ---
(Correction to comment #2)

By mistake I referenced wrong comment as description of snippet
http://bugs.ecos.sourceware.org/attachment.cgi?id=1088
The right one is:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001114#c11

Sorry for inconvenience
// Ilija

> > I thought that's what. Another place where we could define SECTION_user
> > macro could be lpc17xx variant linker include file, e.g.
> > 
> >   cortexm/lpc17xx/var/current/include/pkgconf/mlt_cortexm_lpc17xx.ldi
> 
> You'll find an example snippet here:
> http://bugs.ecos.sourceware.org/attachment.cgi?id=1088
> and here's a description:
> [Wrong - see above] http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001114#c7 
>

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #4 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-13 19:50:11 GMT ---
(In reply to comment #2)

Hi Ilija,

> Sergei
> 
> There has been discussion on this in bug 1001114 where user sections were
> introduced, and this bug is an outcome of that discussion. Please refer to bug
> 1001114 for a complete evolution.

Indeed, I read comments on bug 1001114 before to post as I have got
doubts about the placement for new macro (architecture ld script),
but that is *mine*.

To be clear. All SECTION_xxx macros in arch. ld script have stable set
of arguments: _region_, _vma_, _lma_; all of them are the very tuned by
their own bodies and SECTION_user with a different set of arguments *IMO*
is something odd.

Well, variants could be CUSTOM_SECTION, DEFINE_SECTION, ABS_SECTION
(though I dislike these enters too), so I asked about variant's land.

[snip]

>   - Shall we need this kind of facility for other future variants and how often?
>   - Is the macro (as is or with reasonable modifications) generic enough to
> enter at architecture level?

Exactly these questions excited my comment 1.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #5 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-13 20:02:40 GMT ---
(In reply to comment #3)

> By mistake I referenced wrong comment as description of snippet
> http://bugs.ecos.sourceware.org/attachment.cgi?id=1088
> The right one is:
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001114#c11

Ilija, thank you. To make life easier you can use an autolinkification
http://www.google.com/search?q=bugzilla+autolinkification

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #6 from John Dallaway <john@dallaway.org.uk> 2011-02-14 07:28:41 GMT ---
Sergei

(In reply to comment #1)

> I thought that's what. Another place where we could define SECTION_user
> macro could be lpc17xx variant linker include file, e.g.
> 
>   cortexm/lpc17xx/var/current/include/pkgconf/mlt_cortexm_lpc17xx.ldi
> 
> This definition could be included from the target's memory layout
> files.
> 
> - variant's source is a good place to comment what is macro for;

The macro is intended to be completely generic, suitable to any variant. We
know that other Cortex-M variants include peripheral memory which could be used
via such a macro. Placing this definition in cortex.ld seems like the right
approach to me. I could envisage a similar definition being added to *.ld for
other architectures in the future.

The *.ldi files were once generated by a memory layout tool and it seems best
to avoid adding arbitrary code to these files so the possibility of
re-introducing such a tool is preserved.

I do agree that the name "SECTION_user()" could lead to some confusion with the
existing SECTION_*() macros which have a different number of parameters. I
would be happy to use a macro name such as "USER_SECTION()" instead.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #7 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-14 08:35:57 GMT ---
(In reply to comment #6)
> The macro is intended to be completely generic, suitable to any variant. We
> know that other Cortex-M variants include peripheral memory which could be
> used via such a macro. Placing this definition in cortex.ld seems like the
> right approach to me. I could envisage a similar definition being added to
> *.ld for other architectures in the future.
> 
> The *.ldi files were once generated by a memory layout tool and it seems best
> to avoid adding arbitrary code to these files so the possibility of
> re-introducing such a tool is preserved.

> I do agree that the name "SECTION_user()" could lead to some confusion with
> the existing SECTION_*() macros which have a different number of parameters.
> I would be happy to use a macro name such as "USER_SECTION()" instead.

John, then I "found" such a name too :-), and I like this name and now
I would argee with your points about macro placement (cortexm.ld).

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-14 09:17:02 GMT ---
(In reply to comment #7)
> (In reply to comment #6)
> > The macro is intended to be completely generic, suitable to any variant. We
> > know that other Cortex-M variants include peripheral memory which could be
> > used via such a macro. Placing this definition in cortex.ld seems like the
> > right approach to me. I could envisage a similar definition being added to
> > *.ld for other architectures in the future.
> > 
> > The *.ldi files were once generated by a memory layout tool and it seems best
> > to avoid adding arbitrary code to these files so the possibility of
> > re-introducing such a tool is preserved.
> 
> > I do agree that the name "SECTION_user()" could lead to some confusion with
> > the existing SECTION_*() macros which have a different number of parameters.
> > I would be happy to use a macro name such as "USER_SECTION()" instead.
> 
> John, then I "found" such a name too :-), and I like this name and now
> I would argee with your points about macro placement (cortexm.ld).

Me too, do you need me to produce a new patch?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #9 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-14 12:34:01 GMT ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
[snip]
> > > I do agree that the name "SECTION_user()" could lead to some confusion
> > > with the existing SECTION_*() macros which have a different number of
> > > parameters.  I would be happy to use a macro name such as
> > > "USER_SECTION()" instead.
> > 
> > John, then I "found" such a name too :-), and I like this name and now I
> > would argee with your points about macro placement (cortexm.ld).
> 
> Me too, do you need me to produce a new patch?

So, we are happy with USER_SECTION(). What's about those SECTION_START,
SECTION_END definitions in the Attachment 1116 ?  Will be they ever
used then? IMO, the names are too generic and seem like the "reserved"
words ...

If you need those defs, what is about USER_LABEL() instead?

#define USER_LABEL(_label_) \
    ...

If we do not need those defs at all, I would be happy with (not tested)

--- a/packages/hal/cortexm/arch/current/src/cortexm.ld
+++ b/packages/hal/cortexm/arch/current/src/cortexm.ld
@@ -268,5 +268,11 @@ OUTPUT_FORMAT(elf32-bigarm)

 #define SECTIONS_END . = ALIGN(4); _end = .; PROVIDE (end = .);

+#define USER_SECTION(_name_, _region_, _vma_, _lma_) \
+    . ## _name_ _vma_ : _lma_ \
+    { __ ## _name_ ## _start = ABSOLUTE (.); \
+    *(. ## _name_)* \
+    __ ## _name_ ## _end = ABSOLUTE (.); }
+
 #include <pkgconf/hal_cortexm.h>
 #include CYGHWR_MEMORY_LAYOUT_LDI

Comments?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #10 from John Dallaway <john@dallaway.org.uk> 2011-02-14 12:44:15 GMT ---
(In reply to comment #9)

> So, we are happy with USER_SECTION(). What's about those SECTION_START,
> SECTION_END definitions in the Attachment 1116 [details] ?  Will be they ever
> used then? IMO, the names are too generic and seem like the "reserved"
> words ...
> 
> If you need those defs, what is about USER_LABEL() instead?
> 
> #define USER_LABEL(_label_) \
>     ...
> 
> If we do not need those defs at all, I would be happy with (not tested)
> 
> --- a/packages/hal/cortexm/arch/current/src/cortexm.ld
> +++ b/packages/hal/cortexm/arch/current/src/cortexm.ld
> @@ -268,5 +268,11 @@ OUTPUT_FORMAT(elf32-bigarm)
> 
>  #define SECTIONS_END . = ALIGN(4); _end = .; PROVIDE (end = .);
> 
> +#define USER_SECTION(_name_, _region_, _vma_, _lma_) \
> +    . ## _name_ _vma_ : _lma_ \
> +    { __ ## _name_ ## _start = ABSOLUTE (.); \
> +    *(. ## _name_)* \
> +    __ ## _name_ ## _end = ABSOLUTE (.); }
> +
>  #include <pkgconf/hal_cortexm.h>
>  #include CYGHWR_MEMORY_LAYOUT_LDI
> 
> Comments?

It does seem preferable to eliminate the SECTION_START() and SECTION_END()
macros if possible. I assume these macros are not used elsewhere.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-14 13:03:08 GMT ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> [snip]
> > > > I do agree that the name "SECTION_user()" could lead to some confusion
> > > > with the existing SECTION_*() macros which have a different number of
> > > > parameters.  I would be happy to use a macro name such as
> > > > "USER_SECTION()" instead.
> > > 
> > > John, then I "found" such a name too :-), and I like this name and now I
> > > would argee with your points about macro placement (cortexm.ld).
> > 
> > Me too, do you need me to produce a new patch?
> 
> So, we are happy with USER_SECTION(). What's about those SECTION_START,
> SECTION_END definitions in the Attachment 1116 [details] ?  Will be they ever
> used then? IMO, the names are too generic and seem like the "reserved"
> words ...
> 
> If you need those defs, what is about USER_LABEL() instead?
> 
> #define USER_LABEL(_label_) \
>     ...
> 
> If we do not need those defs at all, I would be happy with (not tested)
> 
> --- a/packages/hal/cortexm/arch/current/src/cortexm.ld
> +++ b/packages/hal/cortexm/arch/current/src/cortexm.ld
> @@ -268,5 +268,11 @@ OUTPUT_FORMAT(elf32-bigarm)
> 
>  #define SECTIONS_END . = ALIGN(4); _end = .; PROVIDE (end = .);
> 
> +#define USER_SECTION(_name_, _region_, _vma_, _lma_) \
> +    . ## _name_ _vma_ : _lma_ \
> +    { __ ## _name_ ## _start = ABSOLUTE (.); \
> +    *(. ## _name_)* \
> +    __ ## _name_ ## _end = ABSOLUTE (.); }
> +
>  #include <pkgconf/hal_cortexm.h>
>  #include CYGHWR_MEMORY_LAYOUT_LDI
> 
> Comments?

I introduced them because of properties of CPP concatenation ## with respect to
argument prescan.
http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan
They are needed if "_name_" is a macro:

#define FOO "foo"
USER_SECTION(FOO, reg, vma, lma)

Example use case is when the section name is provided via CDL.
I would keep them but we may consider more suitable names.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #12 from John Dallaway <john@dallaway.org.uk> 2011-02-14 13:16:02 GMT ---
(In reply to comment #11)

> I introduced them because of properties of CPP concatenation ## with respect to
> argument prescan.
> http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan
> They are needed if "_name_" is a macro:
> 
> #define FOO "foo"
> USER_SECTION(FOO, reg, vma, lma)
> 
> Example use case is when the section name is provided via CDL.
> I would keep them but we may consider more suitable names.

Ilija, thank you for the clarification. I now agree that we should keep them.
Perhaps they could be renamed to CYG_USER_SECTION_START() and
CYG_USER_SECTION_END() to reduce the possibility of a naming clash?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #13 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-14 13:43:15 GMT ---
(In reply to comment #12)
> (In reply to comment #11)
> 
> > I introduced them because of properties of CPP concatenation ## with respect to
> > argument prescan.
> > http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan
> > They are needed if "_name_" is a macro:
> > 
> > #define FOO "foo"
> > USER_SECTION(FOO, reg, vma, lma)
> > 
> > Example use case is when the section name is provided via CDL.
> > I would keep them but we may consider more suitable names.
> 
> Ilija, thank you for the clarification. I now agree that we should keep them.
> Perhaps they could be renamed to CYG_USER_SECTION_START() and
> CYG_USER_SECTION_END() to reduce the possibility of a naming clash?

John, I take that you are more qualified than me for avoidance of naming clash
so I would accept your choice.

Just one note: The products of these macros can also be useful for application
(zeroing the section or so). Is it possible (and desirable) to place them
somewhere else where they will be available to both cortexm.ld and user?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #14 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-14 15:51:53 GMT ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > 
> > > I introduced them because of properties of CPP concatenation ## with respect to
> > > argument prescan.
> > > http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan
> > > They are needed if "_name_" is a macro:
> > > 
> > > #define FOO "foo"
> > > USER_SECTION(FOO, reg, vma, lma)
> > > 
> > > Example use case is when the section name is provided via CDL.
> > > I would keep them but we may consider more suitable names.
> > 
> > Ilija, thank you for the clarification. I now agree that we should keep them.
> > Perhaps they could be renamed to CYG_USER_SECTION_START() and
> > CYG_USER_SECTION_END() to reduce the possibility of a naming clash?
> 
> John, I take that you are more qualified than me for avoidance of naming clash
> so I would accept your choice.
> 
> Just one note: The products of these macros can also be useful for application
> (zeroing the section or so). Is it possible (and desirable) to place them
> somewhere else where they will be available to both cortexm.ld and user?

I owe you some further explanation. If used from application,
CYG_USER_SECTION_START() and CYG_USER_SECTION_END() shall be subject to
argument prescan too, so they can't be called directly if _name_ is a macro.
Their usage should be through a proxy, something like:

#define APP_USER_SECTION_START(_name_) CYG_USER_SECTION_START(_name_)

then

#define FOO foo
APP_USER_SECTION_START(FOO)

should expand to __foo_start

Is this becoming too complex?
I am going to make some use case and put it to test.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #15 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-14 18:34:18 GMT ---
(In reply to comment #11)
> I introduced them because of properties of CPP concatenation ## with
> respect to argument prescan.
> http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan
> They are needed if "_name_" is a macro:
>
> #define FOO "foo"
> USER_SECTION(FOO, reg, vma, lma)
>
> Example use case is when the section name is provided via CDL.  I
> would keep them but we may consider more suitable names.

Maybe "complexity" starts in the target's config, as that CDL booldata
(for the section's name) was set as a string

     default_value { "foo" }

In fact then in the most we need to manage the labels and addresses
(!strings). If we avoid the first stringification, i.e. define in CDL

     default_value foo

then we will have destringified things in pkgconf/* like

#define CYGHWR_~~~_FOO foo
#define CYGHWR_~~~_FOO_foo

And CYGHWR_~~~_...FOO is ready to use in .ld, .ldi, .h files, is it
not? Well, I call the LWIP's MEM_SECTION macro. If it make life easier,
I would prefer to add 1 "extra" line in lwipopts.h

#define STRINGIFY(x) #x
#define MEM_SECTION CYGBLD_ATTRIB_SECTION(STRINFIFY(CYGHWR_~~~_xxxFOO))

It seems to me this would let us do not use complex de-stringify macros in
arch. ld script.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #16 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-14 21:06:02 GMT ---
Created an attachment (id=1127)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1127)
CYG_USER_SECTION_XXX() macro use/test case.

(In reply to comment #15)
> (In reply to comment #11)

Sergei, This looks like solution as a solution for provision of section name
from CDL, but in cortexm.ld/USER_SECTION() we still need concatenation in order
to get __foo_start and __foo_end . Same is for user application should it need
to perform some operation on section. Please look at attached use/test case.

About the attached use/test case:

Due to prescan we need proxies. In the submitted example I am using John's
names CYG_USER_SECTION_XXX() for proxies since they are supposed to appear in
user code. Concatenation macros are named __CYG_USER_SECTION_XXX() respectively
and they are also used by USER_SECTION() (see NOTE below.)

The example includes both correct and wrong code (with respect to prescan)
selectable by TRY_RIGHT switch.
This example should be combined with cortexm_ld_1.diff, the patch that I am
posting in following attachment.

NOTE: __CYG_USER_SECTION_XXX() macros, for this example also appear (as a
copypaste) in cortexm.ld since I couldn't locate a suitable header.



> > I introduced them because of properties of CPP concatenation ## with
> > respect to argument prescan.
> > http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan
> > They are needed if "_name_" is a macro:
> >
> > #define FOO "foo"
> > USER_SECTION(FOO, reg, vma, lma)
> >
> > Example use case is when the section name is provided via CDL.  I
> > would keep them but we may consider more suitable names.
> 
> Maybe "complexity" starts in the target's config, as that CDL booldata
> (for the section's name) was set as a string
> 
>      default_value { "foo" }
> 
> In fact then in the most we need to manage the labels and addresses
> (!strings). If we avoid the first stringification, i.e. define in CDL
> 
>      default_value foo
> 
> then we will have destringified things in pkgconf/* like
> 
> #define CYGHWR_~~~_FOO foo
> #define CYGHWR_~~~_FOO_foo
> 
> And CYGHWR_~~~_...FOO is ready to use in .ld, .ldi, .h files, is it
> not? Well, I call the LWIP's MEM_SECTION macro. If it make life easier,
> I would prefer to add 1 "extra" line in lwipopts.h
> 
> #define STRINGIFY(x) #x
> #define MEM_SECTION CYGBLD_ATTRIB_SECTION(STRINFIFY(CYGHWR_~~~_xxxFOO))
> 
> It seems to me this would let us do not use complex de-stringify macros in
> arch. ld script.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1116|0                           |1
        is obsolete|                            |

--- Comment #17 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-14 21:19:52 GMT ---
Created an attachment (id=1128)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1128)
USER_SECTION() macro corresponding to attachment 1127 (for review)

Here I attach the renamed macro USER_SECTION(). It is accompanied by use/test
case provided in attachment 1127 and described in Comment 16. The naming of
__CYG_USER_SECTION_START() and __CYG_USER_SECTION_END() is only a proposal, and
is explained in Comment 16.

NOTE: Due to reasons explained in Comment 16 __CYG_USER_SECTION_XXX() macros
have copies in both cortexm.ld and use/test case code.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #18 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-14 22:02:17 GMT ---
(In reply to comment #16 and comment #17)

Ilija, thank you for clarifications and snippets. I get it. However I
would rename the undescored macros (__CYG_USER_SECTION_*), e.g.

#define CYG_LINK_SECTION_START(_name_) __ ## _name_ ## _start
#define CYG_LINK_SECTION_END(_name_) __ ## _name_ ## _end

Variants of prefixes to discuss CYG_LINK, CYG_LOAD, and CYG_LD. That
will mean, - Use them in a linker scripts.

#define CYG_USER_SECTION_START(_name_) CYG_LINK_SECTION_START(_name_)
#define CYG_USER_SECTION_END(_name_) CYG_LINK_SECTION_END(_name_)

The USER means, - Use in a userspace code.

About duplication the declarations. As target.ld scripts ends with

#include <pkgconf/hal_arch.h>
#include CYGHWR_MEMORY_LAYOUT_LDI

We would declare USER_SECTION after that inclusion the arch's header
and that can be a place for standalone declaration:

#include <pkgconf/hal_arch.h>

#if defined(CYG_LINK_SECTION_START) && defined(CYG_LINK_SECTION_END)
#define USER_SECTION(_name_, _region_,  _vma_, _lma_) \
    ._name_ _vma_ : _lma_ \
    { CYG_LINK_SECTION_START(_name_) = ABSOLUTE (.); \
     *(._name_*) \
    CYG_LINK_SECTION_END(_name_) = ABSOLUTE (.); } \
    > _region_
#endif

#include CYGHWR_MEMORY_LAYOUT_LDI

So, the place to define CYG_{USER,LINK} macros would be hal_cortexm.h.
I hope that I did not "break" something again :-)

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #19 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-14 22:41:59 GMT ---
(In reply to comment #18)

[snip]

> So, the place to define CYG_{USER,LINK} macros would be hal_cortexm.h.

By the way, can not we all define in the header file?

  CYG_LINK_SECTION_{START,END}
  CYG_USER_SECTION_{START,END}

and

  USER_SECTION

John, is there a pitfall?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #20 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-15 09:50:42 GMT ---
(In reply to comment #18)
> (In reply to comment #16 and comment #17)
> 
> Ilija, thank you for clarifications and snippets. I get it. However I
> would rename the undescored macros (__CYG_USER_SECTION_*), e.g.
> 
> #define CYG_LINK_SECTION_START(_name_) __ ## _name_ ## _start
> #define CYG_LINK_SECTION_END(_name_) __ ## _name_ ## _end
> 
> Variants of prefixes to discuss CYG_LINK, CYG_LOAD, and CYG_LD. That
> will mean, - Use them in a linker scripts.
> 
> #define CYG_USER_SECTION_START(_name_) CYG_LINK_SECTION_START(_name_)
> #define CYG_USER_SECTION_END(_name_) CYG_LINK_SECTION_END(_name_)
> 
> The USER means, - Use in a userspace code.

I'm not quite convinced about this notation, I consider USER_SECTION a stem for
all related macro names. I decided to prefix concatenation with __ because they
are supposed to be kind of "hidden", but it may be just my view.

However if some of "linker" variants is opted I would prefer LD as this acronym
is associated with linker staff through the code (target.ld, mlt*.ldi, etc).

> 
> About duplication the declarations. As target.ld scripts ends with
> 
> #include <pkgconf/hal_arch.h>
> #include CYGHWR_MEMORY_LAYOUT_LDI
> 
> We would declare USER_SECTION after that inclusion the arch's header
> and that can be a place for standalone declaration:
> 
> #include <pkgconf/hal_arch.h>
> #if defined(CYG_LINK_SECTION_START) && defined(CYG_LINK_SECTION_END)
> #define USER_SECTION(_name_, _region_,  _vma_, _lma_) \
>     ._name_ _vma_ : _lma_ \
>     { CYG_LINK_SECTION_START(_name_) = ABSOLUTE (.); \
>      *(._name_*) \
>     CYG_LINK_SECTION_END(_name_) = ABSOLUTE (.); } \
>     > _region_
> #endif
> 
> #include CYGHWR_MEMORY_LAYOUT_LDI
> 
> So, the place to define CYG_{USER,LINK} macros would be hal_cortexm.h.
> I hope that I did not "break" something again :-)

I'm not sure if it is proper to place such stuff in a file generated from CDL.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #21 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-15 12:28:41 GMT ---
(In reply to comment #20)
> (In reply to comment #16 and comment #17)

> I'm not quite convinced about this notation, I consider USER_SECTION a
> stem for all related macro names. I decided to prefix concatenation with
> __ because they are supposed to be kind of "hidden", but it may be just
> my view.

Ilija, today I see that I was wrong. You are right. Agreed.

> > So, the place to define CYG_{USER,LINK} macros would be hal_cortexm.h.

> I'm not sure if it is proper to place such stuff in a file generated
> from CDL.

Yes, I agree with this your point too. Thank you for your clarifications.

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #22 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-15 15:00:38 GMT ---
(In reply to comment #16)

> About the attached use/test case:
> 
> Due to prescan we need proxies. In the submitted example I am using John's
> names CYG_USER_SECTION_XXX() for proxies since they are supposed to appear in
> user code. Concatenation macros are named __CYG_USER_SECTION_XXX() respectively
> and they are also used by USER_SECTION() (see NOTE below.)
> 
> The example includes both correct and wrong code (with respect to prescan)
> selectable by TRY_RIGHT switch.
> This example should be combined with cortexm_ld_1.diff, the patch that I am
> posting in following attachment.
> 
> NOTE: __CYG_USER_SECTION_XXX() macros, for this example also appear (as a
> copypaste) in cortexm.ld since I couldn't locate a suitable header.

Sometimes the solution is doing nothing or next to nothing.

Since method for production of section boundaries is fixed, straight-forward
and common (for all sections): __<section_name>_start __<section_name>_end, it
could be documented (possibly within
http://ecos.sourceware.org/docs-latest/ref/hal-linker-scripts.html ) with some
code snippet for zeroing of section.

I guess USER_SECTION() would need a proper documentation anyway.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #23 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-15 21:00:43 GMT ---
Hi

(In reply to comment #22)
> Sometimes the solution is doing nothing or next to nothing.

Fortunately, it happens sometimes.

> Since method for production of section boundaries is fixed,
> straight-forward and common (for all sections): __<section_name>_start
> __<section_name>_end, it could be documented (possibly within
> http://ecos.sourceware.org/docs-latest/ref/hal- linker-scripts.html )
> with some code snippet for zeroing of section.
> 
> I guess USER_SECTION() would need a proper documentation anyway.

Honestly, I could not grasp why you need START/END macros (then you have
convinced me). The first picture in my head was. A HAL/MLT designer (not
CT user) using USER_SECTION macro "describes" a few random access memory
regions for new CPU.  For example, 'mem1', 'mem2', 'mem3' sections. This
HAL/MLT designer provides and a support to init (clear) the regions, so,
he/she knows the names.  It is clear to him/her to use __mem1_start,
__mem1_end, etc. as external labels (he/she knows what USER_SECTION()
macro is).  He/she is the HAL designer.  Then if they want they can
provide via CDL rules a few choices for CT user, for example, to obtain
some rooms in one from a few (one from from one) section (I mean a choice
the values are allowed by our designer), i.e. with CDL func. legal_values
{ mem1 mem2 mem3 }, I dislike an idea to allow CT user to name the
sections and "to code" in C/CPP using "complex" macros. But, this is mine.

So, we can stay on USER_SECTION() innovation only. What your verdict be?
Will HAL/MLT designer be happy with it? As for me I like this rollback.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #24 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-15 22:37:53 GMT ---
(In reply to comment #23)
> Hi
> 
> (In reply to comment #22)
> > Sometimes the solution is doing nothing or next to nothing.
> 
> Fortunately, it happens sometimes.
> 
> > Since method for production of section boundaries is fixed,
> > straight-forward and common (for all sections): __<section_name>_start
> > __<section_name>_end, it could be documented (possibly within
> > http://ecos.sourceware.org/docs-latest/ref/hal- linker-scripts.html )
> > with some code snippet for zeroing of section.
> > 
> > I guess USER_SECTION() would need a proper documentation anyway.
> 
> Honestly, I could not grasp why you need START/END macros (then you have
> convinced me). The first picture in my head was. A HAL/MLT designer (not
> CT user) using USER_SECTION macro "describes" a few random access memory
> regions for new CPU.  For example, 'mem1', 'mem2', 'mem3' sections. This
> HAL/MLT designer provides and a support to init (clear) the regions, so,
> he/she knows the names.  It is clear to him/her to use __mem1_start,
> __mem1_end, etc. as external labels (he/she knows what USER_SECTION()
> macro is).  He/she is the HAL designer.  Then if they want they can
> provide via CDL rules a few choices for CT user, for example, to obtain
> some rooms in one from a few (one from from one) section (I mean a choice
> the values are allowed by our designer), i.e. with CDL func. legal_values
> { mem1 mem2 mem3 }, I dislike an idea to allow CT user to name the
> sections and "to code" in C/CPP using "complex" macros. But, this is mine.
> 
> So, we can stay on USER_SECTION() innovation only. What your verdict be?
> Will HAL/MLT designer be happy with it? As for me I like this rollback.

Yea, that's it, I sometimes reach for more generality than practice needs.
Sorry for confusion and thank you for your patience.
I hope that HAL/MLT designers shall be happy, but even if someone convinces us
that life without them is impossible (which is unlikely) it would be possible
re-introduce them without breaking backward compatibility since for plain (non
macro) names they have no effect.

Now I agree with you to omit START/END macros.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #25 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-16 09:50:22 GMT ---
Hi

In comment 9 Sergei wrote:
> If we do not need those defs at all, I would be happy with (not tested)

In comment 10 John wrote:
> It does seem preferable to eliminate the SECTION_START() and SECTION_END()
> macros if possible. I assume these macros are not used elsewhere.

In comment 23 Ilija wrote:
> Now I agree with you to omit START/END macros.

Consensus? If it is, Ilija, could you, please, submit a final patch for
cortexm.ld after testing?

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #26 from John Dallaway <john@dallaway.org.uk> 2011-02-16 10:11:25 GMT ---
(In reply to comment #25)

> In comment 9 Sergei wrote:
> > If we do not need those defs at all, I would be happy with (not tested)
> 
> In comment 10 John wrote:
> > It does seem preferable to eliminate the SECTION_START() and SECTION_END()
> > macros if possible. I assume these macros are not used elsewhere.
> 
> In comment 23 Ilija wrote:
> > Now I agree with you to omit START/END macros.
> 
> Consensus? If it is, Ilija, could you, please, submit a final patch for
> cortexm.ld after testing?

If I've understood correctly, you (Ilija and Sergei) are now in agreement that
peripheral memory section names will need not require de-stringification. I
agree with this. In fact, I expect peripheral memory sections will typically
have fixed names. Packages like lwIP will be configured to use the section name
provided by the HAL package, not vice-versa.

So lets eliminate the SECTION_START() and SECTION_END() macros and add a single
USER_SECTION() macro to cortexm.ld. We can check this in ahead of the LPC17xx
contribution and it will be one less thing to hold in our minds.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #27 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-16 11:59:49 GMT ---
(In reply to comment #25)
> Hi
> 
> In comment 9 Sergei wrote:
> > If we do not need those defs at all, I would be happy with (not tested)
> 
> In comment 10 John wrote:
> > It does seem preferable to eliminate the SECTION_START() and SECTION_END()
> > macros if possible. I assume these macros are not used elsewhere.
> 
> In comment 23 Ilija wrote:
> > Now I agree with you to omit START/END macros.
> 
> Consensus? If it is, Ilija, could you, please, submit a final patch for
> cortexm.ld after testing?

It does compile, but to be prudent I want to test runtime with LPC17xx and
lwIP. I am on a trip, but I am making arrangement for late evening.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #28 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-02-16 12:15:33 GMT ---
John wrote:
> So lets eliminate the SECTION_START() and SECTION_END() macros and add
> a single USER_SECTION() macro to cortexm.ld. We can check this in ahead
> of the LPC17xx contribution and it will be one less thing to hold in
> our minds.

Yes!

Ilija writes:
> It does compile, but to be prudent I want to test runtime with LPC17xx
> and lwIP.  I am on a trip, but I am making arrangement for late evening.

Ilija, thank you. As I have no CORTEX-M targets I'll be very grateful
for your help.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1127|0                           |1
        is obsolete|                            |
   Attachment #1128|0                           |1
        is obsolete|                            |

--- Comment #29 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-17 00:08:42 GMT ---
Created an attachment (id=1130)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1130)
USER_SECTION() cleaned up and tested.

Here is the USER_SECTION() with omitted START/END macros. I made tests with
LPC17xx + lwIP (simple mode). mlt*.ldi file employs two USER_SECTIONs.

Compiles without warnings, and runs simple http server.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |CURRENTRELEASE
         AssignedTo|unassigned@bugs.ecos.source |john@dallaway.org.uk
                   |ware.org                    |

--- Comment #30 from John Dallaway <john@dallaway.org.uk> 2011-02-17 14:19:29 GMT ---
Ilija, patch checked-in. Thank you for the contribution.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001142] User defined linker sections.

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001142

--- Comment #31 from Ilija Kocho <ilijak@siva.com.mk> 2011-02-17 14:50:20 GMT ---
(In reply to comment #30)
> Ilija, patch checked-in. Thank you for the contribution.

John, Sergei, many thanks for review and patience.

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.