[Bug 1001344] New: Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[Bug 1001344] New: Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

           Summary: Allow nc_test_slave for lwIP to compile for targets
                    with 128KiB RAM.
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: All
            Status: NEW
          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
             Group: eCos
             Class: Advice Request


Created an attachment (id=1377)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1377)
Reduce stack usage of nc_test_slave

Network characterization test for lwIP (nc_test_slave.c) doesn't compile for
targets with RAM <= 128KiB. The problem can be solved by reducing stack sizes
of several threads.

A patch that solves the problem for targets with 128KiB RAM is attached for
review. The patch has been tested on Cortex-M4/Kinetis K60 with 128KiB RAM.

Since some thread stacks have been reduced, it would be good to check
compatibility on other architectures.

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #1 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-09-26 21:11:01 BST ---
(In reply to comment #0)
> Created an attachment (id=1377)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1377)
> Reduce stack usage of nc_test_slave
> 
> Network characterization test for lwIP (nc_test_slave.c) doesn't
> compile for targets with RAM <= 128KiB. The problem can be solved by
> reducing stack sizes of several threads.
> 
> A patch that solves the problem for targets with 128KiB RAM is
> attached for review. The patch has been tested on Cortex-M4/Kinetis
> K60 with 128KiB RAM.
> 
> Since some thread stacks have been reduced, it would be good to check
> compatibility on other architectures.

Hi Ilija,

I have one **minor** remark regarding attachment 1377. I would use
ECHO_STACK_SIZE in the patch instead proposed name (TMAIN_STACK_SIZE),
IMO, such "adjusted" names would look nicer

  MAIN_STACK_SIZE
  LOAD_STACK_SIZE
  IDLE_STACK_SIZE
  ECHO_STACK_SIZE

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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2011-09-26 22:30:15 BST ---
(In reply to comment #1)
> (In reply to comment #0)
> > Created an attachment (id=1377)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1377) [details]
> > Reduce stack usage of nc_test_slave

> 
> Hi Ilija,
> 
> I have one **minor** remark regarding attachment 1377 [details]. I would use
> ECHO_STACK_SIZE in the patch instead proposed name (TMAIN_STACK_SIZE),
> IMO, such "adjusted" names would look nicer

Thanks for comment Sergei.

I selected stack names to reflect thread names. Regarding your proposal I
assume that you mean MAIN_STACK_SIZE => ECHO_STACK_SIZE rather than TMAIN...,
aren't you?

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.

[Bug 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #3 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-09-27 06:45:27 BST ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > Created an attachment (id=1377)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1377) [details] Reduce
stack usage of
> > > nc_test_slave
> 
> > 
> > Hi Ilija,
> > 
> > I have one **minor** remark regarding attachment 1377 [details]. I
> > would use ECHO_STACK_SIZE in the patch instead proposed name
> > (TMAIN_STACK_SIZE), IMO, such "adjusted" names would look nicer
> 
> Thanks for comment Sergei.
> 
> I selected stack names to reflect thread names. Regarding your
> proposal I assume that you mean MAIN_STACK_SIZE => ECHO_STACK_SIZE
> rather than TMAIN..., aren't you?

Hmm. I see

@@ -748,7 +750,7 @@
                       0,                        // entry parameter
                       "socket echo test",       // Name
                       &stack[0],                // Stack
-                      STACK_SIZE,               // Size
+                      TMAIN_STACK_SIZE,         // Size
                       &thread_handle,           // Handle
                       &thread_data              // Thread data structure
             );

So, I've meant s/TMAIN/ECHO/.

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2011-09-27 08:34:44 BST ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > (In reply to comment #0)
> > > > Created an attachment (id=1377)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1377) [details]
[details] Reduce stack usage of
> > > > nc_test_slave
> > 
> > > 
> > > Hi Ilija,
> > > 
> > > I have one **minor** remark regarding attachment 1377 [details] [details]. I
> > > would use ECHO_STACK_SIZE in the patch instead proposed name
> > > (TMAIN_STACK_SIZE), IMO, such "adjusted" names would look nicer
> > 
> > Thanks for comment Sergei.
> > 
> > I selected stack names to reflect thread names. Regarding your
> > proposal I assume that you mean MAIN_STACK_SIZE => ECHO_STACK_SIZE
> > rather than TMAIN..., aren't you?
> 
> Hmm. I see
> 
> @@ -748,7 +750,7 @@
>                        0,                        // entry parameter
>                        "socket echo test",       // Name
>                        &stack[0],                // Stack
> -                      STACK_SIZE,               // Size
> +                      TMAIN_STACK_SIZE,         // Size
>                        &thread_handle,           // Handle
>                        &thread_data              // Thread data structure
>              );
> 
> So, I've meant s/TMAIN/ECHO/.

OK. I see, diff doesn't show complete entry. The thread entry function is named
tmain. Here it is:

    // Create a main thread, so we can run the scheduler and have time 'pass'
    cyg_thread_create(10,                       // Priority
                      tmain,                    // entry
                      0,                        // entry parameter
                      "socket echo test",       // Name
                      &stack[0],                // Stack
                      TMAIN_STACK_SIZE,         // Size
                      &thread_handle,           // Handle
                      &thread_data              // Thread data structure
            );
    cyg_thread_resume(thread_handle);           // Start it

And tmain() doesn't do any echoing, it merely inits lwIP and starts thread
"main" - entry point net_test(). "main" performs echoing and that's why I
thought you were refering to MAIN_STACK_SIZE.
Anyway, now I see that I was not fully consistent. Maybe I should put
TEST_STACK_SIZE instead of MAIN_STACK_SIZE. Then we shall have:

  TEST_STACK_SIZE
  LOAD_STACK_SIZE
  IDLE_STACK_SIZE
  TMAIN_STACK_SIZE

What do you mean?

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #5 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-09-27 10:05:53 BST ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> > > > (In reply to comment #0)
> > > > > Created an attachment (id=1377)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1377) [details]
[details] Reduce stack usage
> of
> > > > > nc_test_slave
> > > 
> > > > 
> > > > Hi Ilija,
> > > > 
> > > > I have one **minor** remark regarding attachment 1377 [details] [details].
> I
> > > > would use ECHO_STACK_SIZE in the patch instead proposed name
> > > > (TMAIN_STACK_SIZE), IMO, such "adjusted" names would look nicer
> > > 
> > > Thanks for comment Sergei.
> > > 
> > > I selected stack names to reflect thread names. Regarding your
> > > proposal I assume that you mean MAIN_STACK_SIZE => ECHO_STACK_SIZE
> > > rather than TMAIN..., aren't you?
> > 
> > Hmm. I see
> > 
> > @@ -748,7 +750,7 @@
> >                        0,                        // entry parameter
> >                        "socket echo test",       // Name
> >                        &stack[0],                // Stack
> > -                      STACK_SIZE,               // Size
> > +                      TMAIN_STACK_SIZE,         // Size
> >                        &thread_handle,           // Handle
> >                        &thread_data              // Thread data structure
> >              );
> > 
> > So, I've meant s/TMAIN/ECHO/.
> 
> OK. I see, diff doesn't show complete entry. The thread entry function is named
> tmain. Here it is:
> 
>     // Create a main thread, so we can run the scheduler and have time 'pass'
>     cyg_thread_create(10,                       // Priority
>                       tmain,                    // entry
>                       0,                        // entry parameter
>                       "socket echo test",       // Name
>                       &stack[0],                // Stack
>                       TMAIN_STACK_SIZE,         // Size
>                       &thread_handle,           // Handle
>                       &thread_data              // Thread data structure
>             );
>     cyg_thread_resume(thread_handle);           // Start it
> 
> And tmain() doesn't do any echoing, it merely inits lwIP and starts thread
> "main" - entry point net_test(). "main" performs echoing and that's why I
> thought you were refering to MAIN_STACK_SIZE.
> Anyway, now I see that I was not fully consistent. Maybe I should put
> TEST_STACK_SIZE instead of MAIN_STACK_SIZE. Then we shall have:
> 
>   TEST_STACK_SIZE
>   LOAD_STACK_SIZE
>   IDLE_STACK_SIZE
>   TMAIN_STACK_SIZE
> 
> What do you mean?

Stupid me. Of course diff -u5 would avoid my "renaming" as I did not look on
the test's source (it's bad thing from my side). I take aside my request.

I'm sorry that I waste your time. Now all clear fo me.

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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #6 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-10-02 15:36:30 BST ---
Thus, no comments were here anymore. I would like commit the patch. Jlija, can
you provide the ChangeLog's record, please.

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

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

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

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2011-10-02 18:22:48 BST ---
Created an attachment (id=1384)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1384)
Reduce stack usage of nc_test_slave (corrected typo)

Some typo corrections.

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2011-10-02 18:29:02 BST ---
Created an attachment (id=1385)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1385)
ChangeLog

(In reply to comment #6)
> Thus, no comments were here anymore. I would like commit the patch. Jlija, can
> you provide the ChangeLog's record, please.

Here it is Sergei, thank you. I was waiting if somebody tries on other
architecture. In meantime we tested on X86 architecture - works.

Regards
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.

[Bug 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

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

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

--- Comment #9 from Ilija Kocho <ilijak@siva.com.mk> 2011-10-02 18:31:56 BST ---
Created an attachment (id=1386)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1386)
ChangeLog

Ups, another typo. sorry.

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

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

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

--- Comment #10 from Ilija Kocho <ilijak@siva.com.mk> 2011-10-02 18:35:43 BST ---
Created an attachment (id=1387)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1387)
ChangeLog

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #11 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-10-02 18:49:52 BST ---
(In reply to comment #8)
> (In reply to comment #6)
> > Thus, no comments were here anymore. I would like commit the patch. Jlija,
> > can you provide the ChangeLog's record, please.
> 
> Here it is Sergei, thank you. I was waiting if somebody tries on other
> architecture. In meantime we tested on X86 architecture - works.

Ilija, thank you (I've got the latest).

I would try to test the modified test on some ARM7TDMI target (if you did not
try the same) and may be on Linux synthetic.

Sergei

> Regards
> 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.

[Bug 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #12 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2011-10-02 20:06:07 BST ---
(In reply to comment #11)
> (In reply to comment #8)
> > (In reply to comment #6)
> > > Thus, no comments were here anymore. I would like commit the
> > > patch.  Jlija, can you provide the ChangeLog's record, please.
> > 
> > Here it is Sergei, thank you. I was waiting if somebody tries on
> > other architecture. In meantime we tested on X86 architecture -
> > works.
> 
> Ilija, thank you (I've got the latest).
> 
> I would try to test the modified test on some ARM7TDMI target (if you
> did not try the same) and may be on Linux synthetic.

Bad news. The stacks are too small to run the test on Linux synthetic
target (I've got 'Segmentation fault' with the patched version). It
seems we need investigate more time to get proper values for 'synth'
target and use another set of the values for CYGPKG_HAL_SYNTH.

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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #13 from Ilija Kocho <ilijak@siva.com.mk> 2011-10-02 20:24:22 BST ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #8)
> > > (In reply to comment #6)
> > > > Thus, no comments were here anymore. I would like commit the
> > > > patch.  Jlija, can you provide the ChangeLog's record, please.
> > > 
> > > Here it is Sergei, thank you. I was waiting if somebody tries on
> > > other architecture. In meantime we tested on X86 architecture -
> > > works.
> > 
> > Ilija, thank you (I've got the latest).
> > 
> > I would try to test the modified test on some ARM7TDMI target (if you
> > did not try the same) and may be on Linux synthetic.
> 
> Bad news. The stacks are too small to run the test on Linux synthetic
> target (I've got 'Segmentation fault' with the patched version). It
> seems we need investigate more time to get proper values for 'synth'
> target and use another set of the values for CYGPKG_HAL_SYNTH.
> 
> Sergei

Thank you for test Sergei. One way to safely overcome this situation would be
to introduce conditional compilation (like for Kernel tests - Bug #1001253),
but I prefer cleaner code and would like to avoid it.
Let us give it more time.

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.

[Bug 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

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

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

--- Comment #14 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-13 11:49:36 BST ---
Created an attachment (id=1754)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1754)
Reduce stack usage of nc_test_slave (MAX_BUF set to 12KiB)

(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > (In reply to comment #8)
> > > > (In reply to comment #6)
> > > > > Thus, no comments were here anymore. I would like commit the
> > > > > patch.  Jlija, can you provide the ChangeLog's record, please.
> > > > 
> > > > Here it is Sergei, thank you. I was waiting if somebody tries on
> > > > other architecture. In meantime we tested on X86 architecture -
> > > > works.
> > > 
> > > Ilija, thank you (I've got the latest).
> > > 
> > > I would try to test the modified test on some ARM7TDMI target (if you
> > > did not try the same) and may be on Linux synthetic.
> > 
> > Bad news. The stacks are too small to run the test on Linux synthetic
> > target (I've got 'Segmentation fault' with the patched version). It
> > seems we need investigate more time to get proper values for 'synth'
> > target and use another set of the values for CYGPKG_HAL_SYNTH.
> > 
> > Sergei

Here I am again after long time. It seem that buffers were too short 8KiB and
messages can be up to 10KiB. Now I fixed this and it is stable. Unfortunately I
can't test on synthetic target since newer Linux kernel (3) doesn't seem to
support ethertap (any suggestion?).
Sergei do u have some time to test on synthetic target pse?

Note: The same bug with MAX_BUF seem to be present in BSD test too. I'm going
to open a bug for that.

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.

[Bug 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #15 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-05-13 12:21:58 BST ---
(In reply to comment #14)
> Here I am again after long time. It seem that buffers were too short
> 8KiB and messages can be up to 10KiB. Now I fixed this and it is
> stable. Unfortunately I can't test on synthetic target since newer
> Linux kernel (3) doesn't seem to support ethertap (any suggestion?).
> Sergei do u have some time to test on synthetic target pse?
> 
> Note: The same bug with MAX_BUF seem to be present in BSD test too.
> I'm going to open a bug for that.
> 
> Ilija

Hi Ilija,

I will test your newest patch on synthetic target for 2.6.32 kernel and
try eCos synthetic networking for the newest Linux kernel since I have
installed the next Ubuntu 12.04 LTS distribution on Virtual Box (it uses
Linux 3.2.0 kernel). I'll let you know then. Thank you for the patch.

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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #16 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-05-14 21:36:05 BST ---
(In reply to comment #15)
> (In reply to comment #14)
> > Here I am again after long time. It seem that buffers were too short
> > 8KiB and messages can be up to 10KiB. Now I fixed this and it is
> > stable. Unfortunately I can't test on synthetic target since newer
> > Linux kernel (3) doesn't seem to support ethertap (any suggestion?).
> > Sergei do u have some time to test on synthetic target pse?
> >
> > Note: The same bug with MAX_BUF seem to be present in BSD test too.
> > I'm going to open a bug for that.

[snip]

> I will test your newest patch on synthetic target for 2.6.32 kernel

Ilija, I have tested nc_test_{master,slave} for synthetic target and NET
template (all NC tests passed as I could expect). The eCos settings were

  cdl_configuration eCos {
      template    net ;
  };
  cdl_option CYGPKG_NET_BUILD_HW_TESTS {
      user_value 1
  };

Hm, not patched lwip' NC test (slave) on synthetic target stalled when
background load is 30% (for BSD stack all loads passed on eCos synthetic
target)

  Set background load = 30%
  Request 18 from 192.168.1.1:7776
  UDP echo - 2048 buffers, 1024 bytes
  Packets out of sequence - recvd: 1, expected: 0

And patched one for 20% load (no 'Segmentation fault' anymore)

  Set background load = 20% 
  Request 18 from 192.168.1.1:7776 
  UDP echo - 2048 buffers, 1024 bytes 
  Packets out of sequence - recvd: 1, expected: 0

So, it seems to me it is another issue with test itself. It would be
good to know, All the lwIP NC tests/loads passed on your real hardware?
For reference,  I used the next eCos configs to build both lwIP' tests

  cdl_configuration eCos {
      template    lwip_eth ;
  };
  cdl_option CYGVAR_DEVS_ETH_ECOSYNTH_ETH0 {
      user_value 1
  };
  cdl_option CYGFUN_LWIP_MODE_SIMPLE {
      user_value 0
  };
  cdl_option CYGFUN_LWIP_MODE_SEQUENTIAL {
      user_value 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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #17 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-05-15 10:25:48 BST ---
(Add to comment #14)
> Unfortunately I can't test on synthetic target since newer Linux
> kernel (3) doesn't seem to support ethertap (any suggestion?).

I've managed it using the latest "Linux for Human Beings" (Ubuntu 12.04
LTS, fresh installation on Oracle VirtualBox) as "described" below

1) sudo apt-get install bridge-utils

2) add to `/etc/network/interfaces'

  auto tap0
  iface tap0 inet manual

  auto br0
  iface br0 inet static
          bridge_ports tap0
          bridge_fd 0
          address 10.1.1.1
          broadcast 10.1.1.255
          netmask 255.255.255.0

/tmp/tmpCpwb07bugz

          netmask 255.255.255.0

3) add to /etc/dnsmasq.conf

  dhcp-range=10.1.1.10,10.1.1.20,255.255.255.0,12h

NOTE: From now Ubuntu uses `dnsmasq' out the box and it starts from
      /etc/init.d/dnsmasq.

Sure, my tweaks for dnsmasq.conf were the very minimal

    $ grep -Ev '(^#|^$)' /etc/dnsmasq.conf
    dhcp-range=10.1.1.10,10.1.1.20,255.255.255.0,12h

4) reboot


HINT: If you build `nc_test_master' on 64-bit host like me, fix CC
variable in net/common/current/tests/make.host

   CC = cc -m32

/tmp/tmpCpwb07bugz

   CC = cc -m32

Well, I've got the same results for NC tests (BSD, lwIP) with Linux
kernel 3.0 as I've got yesterday (see Comment #16).

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #18 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-15 10:55:02 BST ---
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > Here I am again after long time. It seem that buffers were too short
> > > 8KiB and messages can be up to 10KiB. Now I fixed this and it is
> > > stable. Unfortunately I can't test on synthetic target since newer
> > > Linux kernel (3) doesn't seem to support ethertap (any suggestion?).
> > > Sergei do u have some time to test on synthetic target pse?
> > >
> > > Note: The same bug with MAX_BUF seem to be present in BSD test too.
> > > I'm going to open a bug for that.
> 
> [snip]
> 
> > I will test your newest patch on synthetic target for 2.6.32 kernel
> 
> Ilija, I have tested nc_test_{master,slave} for synthetic target and NET
> template (all NC tests passed as I could expect). The eCos settings were
> 
>   cdl_configuration eCos {
>       template    net ;
>   };
>   cdl_option CYGPKG_NET_BUILD_HW_TESTS {
>       user_value 1
>   };
> 

Interesting. On my target /TWR-K70F120M NET/ test crashes (ref Bug 1001586)
unless patched http://bugs.ecos.sourceware.org/attachment.cgi?id=1755.
It is interesting that it doesn't crash on the initial test, that actually uses
10KiB messages, but later.

Just to note that the buffer enlargement is part of Attachment 1754 as well.

> Hm, not patched lwip' NC test (slave) on synthetic target stalled when
> background load is 30% (for BSD stack all loads passed on eCos synthetic
> target)
> 

Perhaps patch similar to http://bugs.ecos.sourceware.org/attachment.cgi?id=1755 
(Bug 1001586) could help for not patched lwIP.

As for Attachment 1754 it reduces thread stacks and I suspect that synthetic
target has larger context than Cortex-M.

Also by experimenting I have found out that some user settings are needed on
lwIP in order to work-out the test well (at least on Cortex-M). Pse see ECM
snippet below, might help with synth. One notable thing is to set Ethernet
thread the same priority as TCP/IP thread. I guess this setting reduces the
thread switches rate - by preventing Ethernet thread to interrupt TCP/IP
thread.
Also CYGNUM_LWIP_TCP_MSS is adapted to test conditions in order to avoid
message fragmentation.

------ lwip.ecm ----------
cdl_configuration eCos {
    description "" ;
    template    default ;
    package CYGPKG_IO_ETH_DRIVERS current ;
    package CYGPKG_NET_LWIP current ;
};

cdl_option CYGFUN_LWIP_MODE_SIMPLE {
    user_value 0
};

cdl_option CYGFUN_LWIP_MODE_SEQUENTIAL {
    user_value 1
};

cdl_option CYGNUM_LWIP_TCP_MSS {
    user_value 1200
};

cdl_option CYGDAT_LWIP_ETH0_DEFAULT {
    user_value 1
};

cdl_option CYGNUM_LWIP_MEM_SIZE {
    user_value 3200
};

cdl_option CYGNUM_LWIP_THREAD_ETH_PRIORITY {
    user_value 8
};

----- End of lwip.ecm ----------------

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #19 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-05-15 12:04:21 BST ---
(In reply to comment #18)
> Also by experimenting I have found out that some user settings are
> needed on lwIP in order to work-out the test well (at least on
> Cortex-M). Pse see ECM snippet below, might help with synth. One
> notable thing is to set Ethernet thread the same priority as TCP/IP
> thread. I guess this setting reduces the thread switches rate - by
> preventing Ethernet thread to interrupt TCP/IP thread.  Also
> CYGNUM_LWIP_TCP_MSS is adapted to test conditions in order to avoid
> message fragmentation.
>
> ------ lwip.ecm ----------
> cdl_configuration eCos {
>     description "" ;
>     template    default ;
>     package CYGPKG_IO_ETH_DRIVERS current ;
>     package CYGPKG_NET_LWIP current ;
> };

[snip]

Ilija, thank you for the description your configuration! I had to
use an eCos `default' template to configure eCos (not `lwip_eth').

Now, the lwIP NC tests finish successfully on eCos synthetic target

  Start TCP echo [2048,1024] - 10ms delay after 1 packet
  TCP echo - 4096 bufs of 1024 bytes in 33.66 seconds - 121.69 KB/S - 0.9969
Mbit/S (M = 10^6)
     slave sent 2048, recvd 2048
  IDLE - ticks: 3671, count: 478667707, 81% idle
  ... Done

I have applied only Attachment #1754 for that. Excuse my mess.

Thank you,
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #20 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-16 01:28:19 BST ---
First, as per bug 1001586 (specifically:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001586#c5 ), I would have
thought the buffer sizes could be smaller: 10240+16+maybe a little more just in
case.

As for the general idea with this patch, I think it is unwise to use fixed
constant sizes for stacks. It's doomed, especially once you involve other, more
stack hungry, architectures than ARM or Cortex.

To get smaller stacks I would suggest starting from
CYGNUM_HAL_STACK_SIZE_MINIMUM, and adding on some numbers of multiples of
CYGNUM_HAL_STACK_FRAME_SIZE plus an extra constant to roughly cover the stack
local variables in the call frame you think you are likely to get, and then add
some more for safety. You can do it so that the numbers you get come out as the
fixed constants you've already determined work for you on the Kinetis, but it
at least means it's more likely to continue to work on other targets. You may
find CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT useful to better inform your
decisions.

Alternatively start from CYGNUM_HAL_STACK_SIZE_TYPICAL and reduce it, but I
think that's a bit riskier, as there's no fixed idea of what is typical, in a
way that makes it easy to reduce.

But I wouldn't just say e.g. "4096", because that's never going to be portable
- for some targets it's excessive, for others it may be too small. The problems
you are seeing with the synth target are probably a symptom of this.

Jifl

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

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

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

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-16 17:03:32 BST ---
Created an attachment (id=1759)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1759)
Reduce stack usage of nc_test_slave fix MAX_BUF 20110516

(In reply to comment #20)
> First, as per bug 1001586 (specifically:
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001586#c5 ), I would have
> thought the buffer sizes could be smaller: 10240+16+maybe a little more just in
> case.

You're right, it may make difference with targets with small memory. My figures
for both buffer and stack sizes come from early experiments. I should have
revised them.

> 
> As for the general idea with this patch, I think it is unwise to use fixed
> constant sizes for stacks. It's doomed, especially once you involve other, more
> stack hungry, architectures than ARM or Cortex.
> 
> To get smaller stacks I would suggest starting from
> CYGNUM_HAL_STACK_SIZE_MINIMUM, and adding on some numbers of multiples of
> CYGNUM_HAL_STACK_FRAME_SIZE plus an extra constant to roughly cover the stack
> local variables in the call frame you think you are likely to get, and then add
> some more for safety. You can do it so that the numbers you get come out as the
> fixed constants you've already determined work for you on the Kinetis, but it
> at least means it's more likely to continue to work on other targets. You may
> find CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT useful to better inform your
> decisions.
> 

Indeed, measurement often offers the best guess :) I just did it for Kinetis
target and here's the printout:

Stack: MINIMUM == 1360, TYPICAL == 3920
Stack usage:
IDLE thread: 340
Background load threads:  244 200 252 252 200
Main thread : 264 

Looks like we have pretty much large margin with CYGNUM_HAL_STACK_SIZE_MINIMUM.
Then we might use the attached patch with minimal changes.

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #22 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-16 17:20:32 BST ---
The minimum stack for Cortex-m does seem quite high - evidently the worst case
for interrupt nesting can affect things badly.

However other architectures do consider the minimum to be a, er, more minimal
minimum (if you see what I mean). So in practice I would add on maybe
4*CYGNUM_HAL_STACK_FRAME_SIZE, and hopefully that won't make things too large
on Kinetis.

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

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

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

--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-17 16:53:30 BST ---
Created an attachment (id=1760)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1760)
nc_test_slave_120512.diff

(In reply to comment #22)
> The minimum stack for Cortex-m does seem quite high - evidently the worst case
> for interrupt nesting can affect things badly.
> 

In general case it might but in this test we only have 2 interrupt sources:
systick (or equivalent) and Ethernet card. If Ethernet card starts nesting
interrupts then it ought to crash.

> However other architectures do consider the minimum to be a, er, more minimal
> minimum (if you see what I mean). So in practice I would add on maybe
> 4*CYGNUM_HAL_STACK_FRAME_SIZE, and hopefully that won't make things too large
> on Kinetis.

This extra stack space isn't a problem for Kinetis. I added it.
By the way I have cleared some compiler warnings (or should I do it in separate
bug?) ChangeLog will be updated accordingly prior to commit.

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #25 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-17 17:12:39 BST ---
(In reply to comment #24)
> 
> In the case of the addition of CYGBLD_ATTRIB_UNUSED, I think it should be
> CYGBLD_ATTRIB_USED, otherwise the calculation may be thrown away which defeats
> the purpose.

To be clear, assuming you agree with that change, then please go ahead and
commit.

Jifl

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #24 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-17 17:12:03 BST ---
(In reply to comment #23)
> 
> This extra stack space isn't a problem for Kinetis. I added it.

Thanks.

> By the way I have cleared some compiler warnings (or should I do it in separate
> bug?) ChangeLog will be updated accordingly prior to commit.

For all but one, yes that's fine. Traditionally the trailing l of "ntohl" meant
it returned a long, but that's not a valid assumption these days since
sizeof(long) is 8 on many systems (it will be fun for the first person who has
to fix all the places in eCos that assume sizeof(long)==4 !).

In the case of the addition of CYGBLD_ATTRIB_UNUSED, I think it should be
CYGBLD_ATTRIB_USED, otherwise the calculation may be thrown away which defeats
the purpose.

Jifl

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #26 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-17 18:03:56 BST ---
(In reply to comment #25)
> (In reply to comment #24)
> > 
> > In the case of the addition of CYGBLD_ATTRIB_UNUSED, I think it should be
> > CYGBLD_ATTRIB_USED, otherwise the calculation may be thrown away which defeats
> > the purpose.
> 
> To be clear, assuming you agree with that change, then please go ahead and
> commit.

CYGBLD_ATTRIB_USED won't suppress the warning:

...
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:
In function ‘do_some_random_computation’:
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:681:5:
warning: ‘used’ attribute ignored [-Wattributes]
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:681:21:
warning: variable ‘x’ set but not used [-Wunused-but-set-variable]
...

CYGBLD_ATTRIB_UNUSED, contrary to what it's name implies, will keep the
variable. Ref: Bug 1001520

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #27 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-17 18:45:11 BST ---
(In reply to comment #26)
> 
> CYGBLD_ATTRIB_UNUSED, contrary to what it's name implies, will keep the
> variable. Ref: Bug 1001520

Oh yes, I'd already forgotten that conversation. The GCC documentation is still
unclear on that point. In that case, we needed a memory access to a particular
location. That happened courtesy of derefencing a volatile pointer set to an
absolute address.

I think this case might be a little different though as the volatile variable
has entirely local scope. No manufactured addresses are involved that could (in
principle) be affected by other agents.

I wonder if you can use both USED and UNUSED at the same time. Given their
intended functions, you should be able to, despite the English meanings
implying they are in some way opposites to each other. That would deal with the
uncertainty.

Jifl

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #28 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-18 08:25:03 BST ---
(In reply to comment #27)
> (In reply to comment #26)
> > 
> > CYGBLD_ATTRIB_UNUSED, contrary to what it's name implies, will keep the
> > variable. Ref: Bug 1001520
> 
> Oh yes, I'd already forgotten that conversation. The GCC documentation is still
> unclear on that point. In that case, we needed a memory access to a particular
> location. That happened courtesy of derefencing a volatile pointer set to an
> absolute address. 
> 
> I think this case might be a little different though as the volatile variable
> has entirely local scope. No manufactured addresses are involved that could (in
> principle) be affected by other agents.
> 

I think that "volatile" is strong enough so compiler wouldn't dare to drop it
even for an automatic variable. Here is the dump for our case. The code is
optimized indeed, but the computation of critical expression is maintained. 

do_some_random_computation(int p)
{
    // Just something that might be "hard"
    volatile double x CYGBLD_ATTRIB_UNUSED;
    x = ((p * 10) * 3.14159) / 180.0;  // radians
     560:    4620          mov    r0, r4
     562:    f010 fea3     bl    112ac <__aeabi_i2d>
     566:    a30c          add    r3, pc, #48    ; (adr r3, 598
<net_load+0x58>)
     568:    e9d3 2300     ldrd    r2, r3, [r3]
     56c:    f010 ff04     bl    11378 <__aeabi_dmul>
     570:    a30b          add    r3, pc, #44    ; (adr r3, 5a0
<net_load+0x60>)
     572:    e9d3 2300     ldrd    r2, r3, [r3]
     576:    f011 f829     bl    115cc <__aeabi_ddiv>
     57a:    340a          adds    r4, #10
net_load(cyg_addrword_t who)
{
    int i;
    while (true) {
        cyg_semaphore_wait(&load_thread_sem[who]);
        for (i = 0;  i < load_thread_level;  i++) {
     57c:    42ac          cmp    r4, r5
static void
do_some_random_computation(int p)
{
    // Just something that might be "hard"
    volatile double x CYGBLD_ATTRIB_UNUSED;
    x = ((p * 10) * 3.14159) / 180.0;  // radians
     57e:    e9cd 0100     strd    r0, r1, [sp]
net_load(cyg_addrword_t who)
{
    int i;
    while (true) {
        cyg_semaphore_wait(&load_thread_sem[who]);
        for (i = 0;  i < load_thread_level;  i++) {
     582:    d1ed          bne.n    560 <net_load+0x20>
            do_some_random_computation(i);
        }
        cyg_thread_delay(1);  // Wait until the next 'tick'
     584:    2001          movs    r0, #1
     586:    2100          movs    r1, #0
     588:    f003 f820     bl    35cc <cyg_thread_delay>
        cyg_semaphore_post(&load_thread_sem[who]);
     58c:    4630          mov    r0, r6
     58e:    f003 f86b     bl    3668 <cyg_semaphore_post>
    }
     592:    e7db          b.n    54c <net_load+0xc>
     594:    f3af 8000     nop.w
     598:    f01b866e     .word    0xf01b866e
     59c:    400921f9     .word    0x400921f9
     5a0:    00000000     .word    0x00000000
     5a4:    40668000     .word    0x40668000
     5a8:    70002cac     .word    0x70002cac
     5ac:    700033c8     .word    0x700033c8


> I wonder if you can use both USED and UNUSED at the same time. Given their
> intended functions, you should be able to, despite the English meanings
> implying they are in some way opposites to each other. That would deal with the
> uncertainty.

Then we get ...warning: ‘used’ attribute ignored... as per Comment #26.

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.

[Bug 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #29 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-18 16:27:46 BST ---
(In reply to comment #28)
> 
> > I think that "volatile" is strong enough so compiler wouldn't dare to drop
> > it even for an automatic variable.

I know that isn't always true. For example, if you call
do_some_random_computation with a constant, gcc will optimise away the
calculation. And with some code, gcc may be able to optimise expressions into
constants that you may not expect it to be able to - it doesn't have to be a
literal constant, but an expression gcc has worked out can only have one value.

For the case of nc_test_slave.c it does appear to be fine for that particular
case - it's not called with a constant. But my point is that your statement is
not generally true that volatile is guaranteed to be respected. And if it isn't
generally true, what guarantee do we have that it will remain true in the case
of nc_test_slave.c's use of it as well.

Anyway...

> > I wonder if you can use both USED and UNUSED at the same time. Given their
> > intended functions, you should be able to, despite the English meanings
> > implying they are in some way opposites to each other. That would deal with the
> > uncertainty.
> 
> Then we get ...warning: ‘used’ attribute ignored... as per Comment #26.

In that case we'll have to trust the GCC people will indeed continue to respect
the volatile because we don't seem to have any alternative.

Jifl

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #30 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-26 20:19:15 BST ---
(In reply to comment #29)
> (In reply to comment #28)
> > 
> > > I think that "volatile" is strong enough so compiler wouldn't dare to drop
> > > it even for an automatic variable.
> 
> I know that isn't always true. For example, if you call
> do_some_random_computation with a constant, gcc will optimise away the
> calculation. And with some code, gcc may be able to optimise expressions into
> constants that you may not expect it to be able to - it doesn't have to be a
> literal constant, but an expression gcc has worked out can only have one value.
> 
> For the case of nc_test_slave.c it does appear to be fine for that particular
> case - it's not called with a constant. But my point is that your statement is
> not generally true that volatile is guaranteed to be respected. And if it isn't
> generally true, what guarantee do we have that it will remain true in the case
> of nc_test_slave.c's use of it as well.
> 
> Anyway...
> 

I haven't encountered such case but I do dump checking whenever I have some
doubt.

> > > I wonder if you can use both USED and UNUSED at the same time. Given their
> > > intended functions, you should be able to, despite the English meanings
> > > implying they are in some way opposites to each other. That would deal with the
> > > uncertainty.
> > 
> > Then we get ...warning: ‘used’ attribute ignored... as per Comment #26.
> 
> In that case we'll have to trust the GCC people will indeed continue to respect
> the volatile because we don't seem to have any alternative.
> 

FAOD, are we go for commit?

Sergei, FYI it works on synthetic target too.

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.

[Bug 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

--- Comment #31 from Jonathan Larmour <jifl@ecoscentric.com> 2012-05-27 01:08:20 BST ---
(In reply to comment #30)
> FAOD, are we go for commit?

Please do.

Jifl

-- 
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 1001344] Allow nc_test_slave for lwIP to compile for targets with 128KiB RAM.

[bugzilla-daemon]

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

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

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

--- Comment #32 from Ilija Kocho <ilijak@siva.com.mk> 2012-05-27 09:32:12 BST ---
Checked in.

Thanks to Sergei and Jifl for testing an comments.

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.