Build failed in Jenkins: NuttX-Nightly-Build #69

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 505.64 KB...]

Configuration/Tool: sim/dsptest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

--2020-03-20 05:30:54--  
https://github.com/ThrowTheSwitch/Unity/archive/v2.4.3.tar.gz
Resolving github.com (github.com)... 192.30.255.113
Connecting to github.com (github.com)|192.30.255.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/ThrowTheSwitch/Unity/tar.gz/v2.4.3 
[following]
--2020-03-20 05:30:54--  
https://codeload.github.com/ThrowTheSwitch/Unity/tar.gz/v2.4.3
Resolving codeload.github.com (codeload.github.com)... 192.30.255.120
Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: 'v2.4.3.tar.gz'

 0K .. .. .. .. .. 5.47M
50K .. .. .. .. .. 10.9M
   100K .. .. .. .. .. 9.37M
   150K .. .. .. .. .. 5.80M
   200K .. .. .. .. .. 5.34M
   250K ...28.3M=0.04s

2020-03-20 05:30:54 (6.91 MB/s) - 'v2.4.3.tar.gz' saved [264150]


Skipping: sim/cxxtest

Configuration/Tool: sim/nsh

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/nsh2

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/configdata

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/bluetooth

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

bluetooth/bluetooth_sockif.c: In function 'bluetooth_poll_local':
bluetooth/bluetooth_sockif.c:617:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
bluetooth/bluetooth_sendto.c: In function 'bluetooth_sendto_eventhandler':
bluetooth/bluetooth_sendto.c:122:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
bluetooth/bluetooth_recvfrom.c: In function 'bluetooth_recvfrom_eventhandler':
bluetooth/bluetooth_recvfrom.c:243:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
bluetooth/bt_netdev.c: In function 'btnet_l2cap_connected':
bluetooth/bt_netdev.c:300:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
bluetooth/bt_netdev.c: In function 'btnet_l2cap_disconnected':
bluetooth/bt_netdev.c:307:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
bluetooth/bt_netdev.c: In function 'btnet_l2cap_encrypt_change':
bluetooth/bt_netdev.c:314:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
bluetooth/bt_netdev.c: In function 'btnet_hci_connected':
bluetooth/bt_netdev.c:467:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
bluetooth/bt_netdev.c: In function 'btnet_hci_disconnected':
bluetooth/bt_netdev.c:474:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
bluetooth/bluetooth_poll.c: In function 'bluetooth_poll':
bluetooth/bluetooth_poll.c:100:2: warning: #warning Missing logic [-Wcpp]
 #warning Missing logic
  ^~~
==

Re: problem with nxsig_timeout (sig_timedwait.c)

[Xiang Xiao]

Maybe we need find all callers of wd_start to ensure that the
callback's prototype hasn't the similar issue.

On Fri, Mar 20, 2020 at 12:36 PM Gregory Nutt  wrote:
>
> The best thing would be if you could submit a verified PR at
> https://github.com/apache/incubator-nuttx
>
> Greg
>
> On 3/19/2020 10:38 AM, Sebastian Perta wrote:
> > Hello,
> >
> > I have no experience and I'm not directly involved with NuttX (I maintain 
> > one of the compilers used to build NuttX),
> > so hopefully I did the right thing in reporting the following issue here.
> > Initially the was reported to me as a problem in the compiler however when 
> > I investigated I found there no problem
> > In the compiler, the problem was in nuttx/sched/signal/sig_timedwait.c at 
> > line 359-360:
> >
> > wd_start(rtcb->waitdog, waitticks,
> >  (wdentry_t)nxsig_timeout, 1, wdparm.pvarg);
> >
> > Looking at the declarations of nxsig_timeout and wdentry_t:
> >
> > static void nxsig_timeout(int argc, wdparm_t itcb)
> > typedef CODE void (*wdentry_t)(int argc, uint32_t arg1, ...);
> >
> > We can see those declarations are incompatible, if we remove the cast the 
> > most compilers (GCC for example) will return
> > an warning (other compilers will go as far as to return an error).
> > ... warning: passing argument ... from incompatible pointer type 
> > [-Wincompatible-pointer-types]
> > ... note: expected 'wdentry_t' {aka 'void (*)(int, int,  ...)'} but 
> > argument is of type 'void (*)(int,  int)'
> >
> > One might think this warning can be safely ignored, especially since it 
> > works in many cases, however this is not
> > generally true it can fail on some targets depending on ABI specification. 
> > This is made clear in the
> > ISO/IEC standard chapter 7.6 more exactly the following statement:
> > "The rightmost parameter plays a special role in the access mechanism, and 
> > will be designated parmN in this description."
> >
> > What this means is that "itcb" from nxsig_timeout can be at a different 
> > location from where "arg1" from wdentry_t is expected it to be.
> >
> > The target for which I've see this problem is Renesas RX. In case of RX 
> > itcb is placed in register R2 while arg1 is placed on the stack.
> >
> > The majority of functions in the code used in this way (casted to 
> > wdentry_t) are variadic as well so this is not a problem in general,
> > just in a few cases (nxsig_timeout is the only one I found so far there 
> > might be a few others)
> > In order to make the code ANSI/ISO compliant nxsig_timeout needs to be made 
> > variadic as well:
> > static void nxsig_timeout(int argc, wdparm_t itcb, ...)
> >
> > I hope you agree with my finding and fix it as this will make the code more 
> > robust (incompatible pointer assignment is unsafe)
> > and more portable (other targets besides Renesas RX in which I have a 
> > vested interest).
> >
> > Thank you,
> > Sebastian
> >
> >
> > Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten 
> > Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 
> > 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: 
> > Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 
> > WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647

Re: problem with nxsig_timeout (sig_timedwait.c)

[Gregory Nutt]

The best thing would be if you could submit a verified PR at 
https://github.com/apache/incubator-nuttx


Greg

On 3/19/2020 10:38 AM, Sebastian Perta wrote:

Hello,

I have no experience and I'm not directly involved with NuttX (I maintain one 
of the compilers used to build NuttX),
so hopefully I did the right thing in reporting the following issue here.
Initially the was reported to me as a problem in the compiler however when I 
investigated I found there no problem
In the compiler, the problem was in nuttx/sched/signal/sig_timedwait.c at line 
359-360:

wd_start(rtcb->waitdog, waitticks,
 (wdentry_t)nxsig_timeout, 1, wdparm.pvarg);

Looking at the declarations of nxsig_timeout and wdentry_t:

static void nxsig_timeout(int argc, wdparm_t itcb)
typedef CODE void (*wdentry_t)(int argc, uint32_t arg1, ...);

We can see those declarations are incompatible, if we remove the cast the most 
compilers (GCC for example) will return
an warning (other compilers will go as far as to return an error).
... warning: passing argument ... from incompatible pointer type 
[-Wincompatible-pointer-types]
... note: expected 'wdentry_t' {aka 'void (*)(int, int,  ...)'} but argument is 
of type 'void (*)(int,  int)'

One might think this warning can be safely ignored, especially since it works 
in many cases, however this is not
generally true it can fail on some targets depending on ABI specification. This 
is made clear in the
ISO/IEC standard chapter 7.6 more exactly the following statement:
"The rightmost parameter plays a special role in the access mechanism, and will be 
designated parmN in this description."

What this means is that "itcb" from nxsig_timeout can be at a different location from 
where "arg1" from wdentry_t is expected it to be.

The target for which I've see this problem is Renesas RX. In case of RX itcb is 
placed in register R2 while arg1 is placed on the stack.

The majority of functions in the code used in this way (casted to wdentry_t) 
are variadic as well so this is not a problem in general,
just in a few cases (nxsig_timeout is the only one I found so far there might 
be a few others)
In order to make the code ANSI/ISO compliant nxsig_timeout needs to be made 
variadic as well:
static void nxsig_timeout(int argc, wdparm_t itcb, ...)

I hope you agree with my finding and fix it as this will make the code more 
robust (incompatible pointer assignment is unsafe)
and more portable (other targets besides Renesas RX in which I have a vested 
interest).

Thank you,
Sebastian


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, 
Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 
Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 
3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. 
no.: DE 14978647

[GitHub] [incubator-nuttx-testing] masayuki2009 commented on issue #16: Add xtensa esp32 boards build support

[GitBox]

masayuki2009 commented on issue #16: Add xtensa esp32 boards build support
URL: 
https://github.com/apache/incubator-nuttx-testing/pull/16#issuecomment-601514544
 
 
   It looks good to me.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx-testing] xiaoxiang781216 merged pull request #16: Add xtensa esp32 boards build support

[GitBox]

xiaoxiang781216 merged pull request #16: Add xtensa esp32 boards build support
URL: https://github.com/apache/incubator-nuttx-testing/pull/16
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx-testing] liuguo09 commented on a change in pull request #16: Add xtensa esp32 boards build support

[GitBox]

liuguo09 commented on a change in pull request #16: Add xtensa esp32 boards 
build support
URL: 
https://github.com/apache/incubator-nuttx-testing/pull/16#discussion_r395425971
 
 

 ##
 File path: testlist/mips-riscv-x86-xtensa.dat
 ##
 @@ -5,3 +5,5 @@
 -nr5m100-nexys4:nsh
 
 /x86
+
+/xtensa
 
 Review comment:
   You are right. Firstly enable xtensa esp32 boards build in full testlit done.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx-testing] xiaoxiang781216 commented on a change in pull request #16: Add xtensa esp32 boards build support

[GitBox]

xiaoxiang781216 commented on a change in pull request #16: Add xtensa esp32 
boards build support
URL: 
https://github.com/apache/incubator-nuttx-testing/pull/16#discussion_r395423947
 
 

 ##
 File path: testlist/mips-riscv-x86-xtensa.dat
 ##
 @@ -5,3 +5,5 @@
 -nr5m100-nexys4:nsh
 
 /x86
+
+/xtensa
 
 Review comment:
   Should we move the change to:
   
https://github.com/apache/incubator-nuttx-testing/blob/master/testlist/full.dat
   since xtensa-esp32-gcc-toolchain is just used for the nightly build.
   So we can enable esp32 step by step.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx-testing] xiaoxiang781216 commented on a change in pull request #16: Add xtensa esp32 boards build support

[GitBox]

xiaoxiang781216 commented on a change in pull request #16: Add xtensa esp32 
boards build support
URL: 
https://github.com/apache/incubator-nuttx-testing/pull/16#discussion_r395423947
 
 

 ##
 File path: testlist/mips-riscv-x86-xtensa.dat
 ##
 @@ -5,3 +5,5 @@
 -nr5m100-nexys4:nsh
 
 /x86
+
+/xtensa
 
 Review comment:
   Should we move the change to:
   
https://github.com/apache/incubator-nuttx-testing/blob/master/testlist/full.dat
   since xtensa-esp32-gcc-toolchain is just used for the nightly build.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Podling Nuttx Report Reminder - April 2020

[jmclean]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 15 April 2020, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, April 01).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Candidate names should not be made public before people are actually
elected, so please do not include the names of potential committers or
PPMC members in your report.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://cwiki.apache.org/confluence/display/INCUBATOR/April2020

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Note: The format of the report has changed to use markdown.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

[GitHub] [incubator-nuttx-testing] liuguo09 commented on issue #16: Add xtensa esp32 boards build support

[GitBox]

liuguo09 commented on issue #16: Add xtensa esp32 boards build support
URL: 
https://github.com/apache/incubator-nuttx-testing/pull/16#issuecomment-601506539
 
 
   Take care to merge the change since github action docker image and matrix 
boards should be updated synchronously.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [incubator-nuttx-testing] liuguo09 opened a new pull request #16: Add xtensa esp32 boards build support

[GitBox]

liuguo09 opened a new pull request #16: Add xtensa esp32 boards build support
URL: https://github.com/apache/incubator-nuttx-testing/pull/16
 
 
   1. Add xtensa esp32 gcc toolchain
   2. Add xtensa esp32 boards into testlist
   
   Note nuttx and apps github action workflows also need update accordingly:
   1. docker image updated with xtensa toolchain firstly
   2. use 'mips-riscv-x86-xtensa'  instead of 'mips-riscv-x86' in matrix boards


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Build errors with inline functions

[Xiang Xiao]

On Fri, Mar 20, 2020 at 6:21 AM Gregory Nutt  wrote:
>
>
> >> -O--> works
> >> -O2  --> works
> >> -O3  --> works
> >> -O0  --> fails
> >> -Os  --> works
> > Because it builds when optimization is on, and because the error you
> > posted in your original post is a linker error, that leads me to the
> > following hypothesis:
> >
> > I think that with optimization turned on, there is some automatic dead
> > code removal happening. That is, functions that are unused are removed
> > from the link. ...
>
> I don't think so.  static inline functions never generate code if they
> are not referenced and included inline.
>

No, inline is just an optimization hint to compiler, compiler can
ignore it as needed(e.g. in O0 case).
Nathan's analysis is right, the problem is that:
1.Compiler doesn't remove the unused mpu_configure_region from the
final image in O0 case
2.mpu_configure_region call  mpu_allocregion
3.But stm32h7 compile and link up_mpu.c(mpu_allocregion implmented
here) only in PROTECTED mode
We can't complain item 1 is the compiler's fault because the standard
never request that compiler must remove the unused function even it's
static or inline.
The problem is that our code depend on the undefined compiler
behaviour(removing the unused function). The fix could be:
1.Include mpu.h conditionally in arch/arm/src/stm32h7/stm32_allocateheap.c:
   #ifdef CONFIG_ARM_MPU
   #  include "mpu.h"
   #endif
2.Always compile and link up_mpu.c in arch/arm/src/stm32h7/Make.defs

> More likely is the fact that inlining is disabled at -O0 and now the
> functions really are implemented as static functions and generate static
> functions.  Now you really do have unreferenced static functions.  Try
> removing the static storage class from the inline prototypes.
>
>
>
> > Those functions, the unused ones removed from the link,
> > are calling other functions that are not found because preprocessor
> > conditional logic (based on Kconfig settings) is excluding them from
> > ever being compiled. But everything builds successfully because the
> > linker doesn't care about resolving dependencies of functions that are
> > never called.
> >
> > But... With optimization turned off, the linker is trying to link
> > everything, including the unused functions, and then it realizes that
> > it can't find the nonexistent functions referenced by the unused
> > functions.
> >
> > How's that for long-winded?
> >
> > Again, this is a *hypothesis* based on everything I read in this thread so 
> > far.
> >
> > You might want to check if your default options include
> > -ffunction-sections, -fdata-sections, and/or -Wl,–gc-sections. If so,
> > that would be in favor of the above.
> >
> > Cheers,
> > Nathan
>
>

problem with nxsig_timeout (sig_timedwait.c)

[Sebastian Perta]

Hello,

I have no experience and I'm not directly involved with NuttX (I maintain one 
of the compilers used to build NuttX),
so hopefully I did the right thing in reporting the following issue here.
Initially the was reported to me as a problem in the compiler however when I 
investigated I found there no problem
In the compiler, the problem was in nuttx/sched/signal/sig_timedwait.c at line 
359-360:

wd_start(rtcb->waitdog, waitticks,
(wdentry_t)nxsig_timeout, 1, wdparm.pvarg);

Looking at the declarations of nxsig_timeout and wdentry_t:

static void nxsig_timeout(int argc, wdparm_t itcb)
typedef CODE void (*wdentry_t)(int argc, uint32_t arg1, ...);

We can see those declarations are incompatible, if we remove the cast the most 
compilers (GCC for example) will return
an warning (other compilers will go as far as to return an error).
... warning: passing argument ... from incompatible pointer type 
[-Wincompatible-pointer-types]
... note: expected 'wdentry_t' {aka 'void (*)(int, int,  ...)'} but argument is 
of type 'void (*)(int,  int)'

One might think this warning can be safely ignored, especially since it works 
in many cases, however this is not
generally true it can fail on some targets depending on ABI specification. This 
is made clear in the
ISO/IEC standard chapter 7.6 more exactly the following statement:
"The rightmost parameter plays a special role in the access mechanism, and will 
be designated parmN in this description."

What this means is that "itcb" from nxsig_timeout can be at a different 
location from where "arg1" from wdentry_t is expected it to be.

The target for which I've see this problem is Renesas RX. In case of RX itcb is 
placed in register R2 while arg1 is placed on the stack.

The majority of functions in the code used in this way (casted to wdentry_t) 
are variadic as well so this is not a problem in general,
just in a few cases (nxsig_timeout is the only one I found so far there might 
be a few others)
In order to make the code ANSI/ISO compliant nxsig_timeout needs to be made 
variadic as well:
static void nxsig_timeout(int argc, wdparm_t itcb, ...)

I hope you agree with my finding and fix it as this will make the code more 
robust (incompatible pointer assignment is unsafe)
and more portable (other targets besides Renesas RX in which I have a vested 
interest).

Thank you,
Sebastian


Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, 
Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 
Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 
3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. 
no.: DE 14978647

Re: Build errors with inline functions

[Gregory Nutt]

More likely is the fact that inlining is disabled at -O0 and now the 
functions really are implemented as static functions and generate 
static functions.  Now you really do have unreferenced static 
functions.  Try removing the static storage class from the inline 
prototypes. 


What would work best for header files is to declare inline functions as 
extern.  Then provide a C file with the inline function definitions.  
this is preferable because it works in all cases:  It works when 
inlining is not enabled and it works with C89 compilers.  This is 
recommended: https://gcc.gnu.org/onlinedocs/gcc/Inline.html


static inline in header files is never recommended: 
https://groups.google.com/forum/#!topic/mozilla.dev.platform/Ulw9HoZbSyQ

Re: Build errors with inline functions

[Gregory Nutt]

More likely is the fact that inlining is disabled at -O0 and now the 
functions really are implemented as static functions and generate 
static functions.  Now you really do have unreferenced static 
functions.  Try removing the static storage class from the inline 
prototypes.


Or try the always_inline attribute.  That is GCC-specific and really 
should not appear directly in source files, but indirectly through 
compiler.h

Re: Build errors with inline functions

[Gregory Nutt]

-O--> works
-O2  --> works
-O3  --> works
-O0  --> fails
-Os  --> works

Because it builds when optimization is on, and because the error you
posted in your original post is a linker error, that leads me to the
following hypothesis:

I think that with optimization turned on, there is some automatic dead
code removal happening. That is, functions that are unused are removed
from the link. ...


I don't think so.  static inline functions never generate code if they 
are not referenced and included inline.


More likely is the fact that inlining is disabled at -O0 and now the 
functions really are implemented as static functions and generate static 
functions.  Now you really do have unreferenced static functions.  Try 
removing the static storage class from the inline prototypes.





Those functions, the unused ones removed from the link,
are calling other functions that are not found because preprocessor
conditional logic (based on Kconfig settings) is excluding them from
ever being compiled. But everything builds successfully because the
linker doesn't care about resolving dependencies of functions that are
never called.

But... With optimization turned off, the linker is trying to link
everything, including the unused functions, and then it realizes that
it can't find the nonexistent functions referenced by the unused
functions.

How's that for long-winded?

Again, this is a *hypothesis* based on everything I read in this thread so far.

You might want to check if your default options include
-ffunction-sections, -fdata-sections, and/or -Wl,–gc-sections. If so,
that would be in favor of the above.

Cheers,
Nathan

Re: Build errors with inline functions

[Nathan Hartman]

On Thu, Mar 19, 2020 at 6:01 PM John Rippetoe
 wrote:
> That's interesting. Maybe there is a difference in the default flags between 
> my compiler and what you and the build server are using. It looks like the 
> default standard for my compiler is gnu90. I haven't done an exhaustive test 
> on all the builds, but for starters here are a few that fail
>
> nucleo-h743i:nsh
> nucleo-h743i:nxlines_oled
> stm32h747i-disco:nsh
>
> I just found that the nucleo-h743xi:pwm config did not fail, so I dug into 
> that and found that compiler optimizations play a role in whether the build 
> completes.  With the "No Optimization" setting selected, the build fails. 
> Turning on "Full Optimization" allows the build to complete. I also tested 
> all of the common custom optimzation levels
>
> -O--> works
> -O2  --> works
> -O3  --> works
> -O0  --> fails
> -Os  --> works

Because it builds when optimization is on, and because the error you
posted in your original post is a linker error, that leads me to the
following hypothesis:

I think that with optimization turned on, there is some automatic dead
code removal happening. That is, functions that are unused are removed
from the link. Those functions, the unused ones removed from the link,
are calling other functions that are not found because preprocessor
conditional logic (based on Kconfig settings) is excluding them from
ever being compiled. But everything builds successfully because the
linker doesn't care about resolving dependencies of functions that are
never called.

But... With optimization turned off, the linker is trying to link
everything, including the unused functions, and then it realizes that
it can't find the nonexistent functions referenced by the unused
functions.

How's that for long-winded?

Again, this is a *hypothesis* based on everything I read in this thread so far.

You might want to check if your default options include
-ffunction-sections, -fdata-sections, and/or -Wl,–gc-sections. If so,
that would be in favor of the above.

Cheers,
Nathan

Re: Build errors with inline functions

[Gregory Nutt]

I just found that the nucleo-h743xi:pwm config did not fail, so I dug into that and found that 
compiler optimizations play a role in whether the build completes.  With the "No 
Optimization" setting selected, the build fails. Turning on "Full Optimization" 
allows the build to complete. I also tested all of the common custom optimzation levels

-O--> works
-O2  --> works
-O3  --> works
-O0  --> fails
-Os  --> works


Okay that makes sense.  At -O0 inlining of functions is disabled.  
Therefore, it is as though the inline qualifier were not there.  Then, 
everytime you include a header file that has static inline functions, 
you will will get warnings that those functions are not used:


LD: nuttx
nuttx/staging/libarch.a(stm32_allocateheap.o): In function 
`mpu_configure_region':
nuttx/arch/arm/src/armv7-m/mpu.h:281: undefined reference to 
`mpu_allocregion'
nuttx/arch/arm/src/armv7-m/mpu.h:296: undefined reference to 
`mpu_log2regionceil'
nuttx/arch/arm/src/armv7-m/mpu.h:298: undefined reference to 
`mpu_log2regionceil'
nuttx/arch/arm/src/armv7-m/mpu.h:315: undefined reference to 
`mpu_subregion'


You can try removing the static from the inline function definitions in 
the header file.  The code should then compile, however, you could also 
get multiply defined functions at link time... Or maybe the linker is 
smart enough to allow multiples???


Putting inline functions in header files introduces lots of problem 
(especially if you are using C89).  If they are to be used in header 
files, at least they should not be declared static.

Re: Build errors with inline functions

[Brennan Ashton]

While we probably should get to the root of the flags and specify them more
completely if needed, I would highly recommend using the gcc compiler built
by ARM.

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm

It is kept quite up-to-date and tends to fix some issue I have had in the
past with the distro delivered packages for embedded builds.
This is also the toolchain our CI system uses.

--Brennan

Re: Build errors with inline functions

[John Rippetoe]

That's interesting. Maybe there is a difference in the default flags between my 
compiler and what you and the build server are using. It looks like the default 
standard for my compiler is gnu90. I haven't done an exhaustive test on all the 
builds, but for starters here are a few that fail 

nucleo-h743i:nsh
nucleo-h743i:nxlines_oled
stm32h747i-disco:nsh

I just found that the nucleo-h743xi:pwm config did not fail, so I dug into that 
and found that compiler optimizations play a role in whether the build 
completes.  With the "No Optimization" setting selected, the build fails. 
Turning on "Full Optimization" allows the build to complete. I also tested all 
of the common custom optimzation levels

-O--> works
-O2  --> works
-O3  --> works
-O0  --> fails
-Os  --> works

The issue crops up in flat builds because of how the build pulls in files based 
on the config. An example is the easiest way to show the issue. Here is one of 
the offending functions from the compiler error

nuttx/staging/libarch.a(stm32_allocateheap.o): In function 
`mpu_configure_region':
nuttx/arch/arm/src/armv7-m/mpu.h:281: undefined reference to `mpu_allocregion'

mpu_allocregion is declared at line 172 of mpu.h but used within the inline 
function mpu_configure_region at line 278 of the same file.  The function 
mpu_allocregion is defined at line 211 of file arch/arm/src/armv7-m/up_mpu.c, 
but this file is not included in the build unless CONFIG_PROTECTED_BUILD is 
defined (line 96 of arc/arm/src/stm32h7/Make.defs). The file mpu.h, which is 
the source of the errors, is non-conditionally included in 
stm32_allocateheap.c, which is a required file for the build.

There are really two issues here (potentially)

1. mpu.h should only be included when mpu support is needed, such as with a 
protected build. I tested this by conditionally including mpu.h only when 
CONFIG_PROTECTED_BUILD is defined and that gave me a clean build. The build 
should be able to complete regardless of whether optimization is used or not. I 
suspect that adding optimization helps me in this case because the compiler 
recognizes that the problematic functions are not used and simply removes them, 
thus getting me around the error. But if I were to switch over to a protected 
build, I'd wager that things might break again if inlining is the issue, which 
leads into number 2 below.

2. The way that compiler.h currently determines inline support is incompatible 
with the defaults on my system, which appears to be gnu90. Given that, what is 
the best way for a user to specify a particular build? And since we need inline 
functions for this code to compile, should we not specify the minimum standard 
necessary in the Make.defs?


Thanks for the help. Sorry this got a little long winded. 

- John 

- Original Message -
From: "Abdelatif Guettouche" 
To: "dev" 
Sent: Thursday, March 19, 2020 2:29:30 PM
Subject: Re: Build errors with inline functions

>
>  The functions the compiler
> is complaining about are defined in up_mpu.c, which is only included for
> protected builds. So it makes sense you wouldn't see the issue when
> building in protected mode.

The issue should be then seen when protected mode is enabled, there where
the MPU is used.
libarch shouldn't contain any MPU related symbol.
I built flat modes as well. All builds complete error free.
You can also see in the nightly build [1], all H7 are building error free.

However, the same issue occurs when trying to build the existing
> H7 boards and with many of the F7 boards as well.
>
What boards are causing the issue?

1.
https://builds.apache.org/view/Incubator%20Projects/job/NuttX-Nightly-Build/68/console

On Thu, Mar 19, 2020 at 2:46 PM John Rippetoe 
wrote:

> I'm using the generic arm-none-eabi toolchain, version 4.84.   OS is
> Ubuntu 16.04.  The contents of my board Make.defs is below.
>
>
> 
> # boards/arm/stm32h7/stm32h753xi-eval2/scripts/Make.defs
> #
> #   Copyright (C) 2018 Gregory Nutt. All rights reserved.
> #   Author: Gregory Nutt 
> #
> # Redistribution and use in source and binary forms, with or without
> # modification, are permitted provided that the following conditions
> # are met:
> #
> # 1. Redistributions of source code must retain the above copyright
> #notice, this list of conditions and the following disclaimer.
> # 2. Redistributions in binary form must reproduce the above copyright
> #notice, this list of conditions and the following disclaimer in
> #the documentation and/or other materials provided with the
> #distribution.
> # 3. Neither the name NuttX nor the names of its contributors may be
> #used to endorse or promote products derived from this software
> #without specific prior written permission.
> #
> # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> # "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> # LIMITED TO, THE IMP

Re: Build errors with inline functions

[Abdelatif Guettouche]

>
>  The functions the compiler
> is complaining about are defined in up_mpu.c, which is only included for
> protected builds. So it makes sense you wouldn't see the issue when
> building in protected mode.

The issue should be then seen when protected mode is enabled, there where
the MPU is used.
libarch shouldn't contain any MPU related symbol.
I built flat modes as well. All builds complete error free.
You can also see in the nightly build [1], all H7 are building error free.

However, the same issue occurs when trying to build the existing
> H7 boards and with many of the F7 boards as well.
>
What boards are causing the issue?

1.
https://builds.apache.org/view/Incubator%20Projects/job/NuttX-Nightly-Build/68/console

On Thu, Mar 19, 2020 at 2:46 PM John Rippetoe 
wrote:

> I'm using the generic arm-none-eabi toolchain, version 4.84.   OS is
> Ubuntu 16.04.  The contents of my board Make.defs is below.
>
>
> 
> # boards/arm/stm32h7/stm32h753xi-eval2/scripts/Make.defs
> #
> #   Copyright (C) 2018 Gregory Nutt. All rights reserved.
> #   Author: Gregory Nutt 
> #
> # Redistribution and use in source and binary forms, with or without
> # modification, are permitted provided that the following conditions
> # are met:
> #
> # 1. Redistributions of source code must retain the above copyright
> #notice, this list of conditions and the following disclaimer.
> # 2. Redistributions in binary form must reproduce the above copyright
> #notice, this list of conditions and the following disclaimer in
> #the documentation and/or other materials provided with the
> #distribution.
> # 3. Neither the name NuttX nor the names of its contributors may be
> #used to endorse or promote products derived from this software
> #without specific prior written permission.
> #
> # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> # "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> # LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
> # FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
> # COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
> # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
> # BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
> # OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
> # AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
> # ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> # POSSIBILITY OF SUCH DAMAGE.
> #
>
> 
>
> include ${TOPDIR}/.config
> include ${TOPDIR}/tools/Config.mk
> include ${TOPDIR}/arch/arm/src/armv7-m/Toolchain.defs
>
> LDSCRIPT = flash.ld
>
> ifeq ($(WINTOOL),y)
>   # Windows-native toolchains
>   DIRLINK = $(TOPDIR)/tools/copydir.sh
>   DIRUNLINK = $(TOPDIR)/tools/unlink.sh
>   MKDEP = $(TOPDIR)/tools/mkwindeps.sh
>   ARCHINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}"
>   ARCHXXINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}"
> -isystem "${shell cygpath -w $(TOPDIR)/include/cxx}"
>   ARCHSCRIPT = -T "${shell cygpath -w
> $(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)}"
> else
>   # Linux/Cygwin-native toolchain
>   MKDEP = $(TOPDIR)/tools/mkdeps$(HOSTEXEEXT)
>   ARCHINCLUDES = -I. -isystem $(TOPDIR)/include
>   ARCHXXINCLUDES = -I. -isystem $(TOPDIR)/include -isystem
> $(TOPDIR)/include/cxx
>   ARCHSCRIPT =
> -T$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)
> endif
>
> CC = $(CROSSDEV)gcc
> CXX = $(CROSSDEV)g++
> CPP = $(CROSSDEV)gcc -E
> LD = $(CROSSDEV)ld
> AR = $(ARCROSSDEV)ar rcs
> NM = $(ARCROSSDEV)nm
> OBJCOPY = $(CROSSDEV)objcopy
> OBJDUMP = $(CROSSDEV)objdump
>
> ARCHCCVERSION = ${shell $(CC) -v 2>&1 | sed -n '/^gcc version/p' | sed -e
> 's/^gcc version \([0-9\.]\)/\1/g' -e 's/[-\ ].*//g' -e '1q'}
> ARCHCCMAJOR = ${shell echo $(ARCHCCVERSION) | cut -d'.' -f1}
>
> ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
>   ARCHOPTIMIZATION = -g
> endif
>
> ifneq ($(CONFIG_DEBUG_NOOPT),y)
>   ARCHOPTIMIZATION += $(MAXOPTIMIZATION) -fno-strict-aliasing
> -fno-strength-reduce -fomit-frame-pointer
> endif
>
> ARCHCFLAGS = -fno-builtin
> ARCHCXXFLAGS = -fno-builtin -fno-exceptions -fcheck-new -fno-rtti
> ARCHWARNINGS = -Wall -Wstrict-prototypes -Wshadow -Wundef
> ARCHWARNINGSXX = -Wall -Wshadow -Wundef
> ARCHDEFINES =
> ARCHPICFLAGS = -fpic -msingle-pic-base -mpic-register=r10
>
> CFLAGS = $(ARCHCFLAGS) $(ARCHWARNINGS) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS)
> $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -pipe
> CPICFLAGS = $(ARCHPICFLAGS) $(CFLAGS)
> CXXFLAGS = $(ARCHCXXFLAGS) $(ARCHWARNINGSXX) $(ARCHOPTIMIZATION)
> $(ARCHCPUFLAGS) $(ARCHXXINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -

Fwd: State of Structure Assignments

[Gregory Nutt]

Subject:State of Structure Assignments
Date:   Thu, 19 Mar 2020 09:22:50 -0600
From:   Gregory Nutt 
To: sdcc-de...@lists.sourceforge.net, dev@nuttx.apache.org


To:  SDCC sdcc-devel List
Cc: NuttX dev list

Hi, all.  I need to know the current state of structure assignments in SDCC.

I am the author of the NuttX operating system and we have long supported 
SDCC for z80 and z180 platforms.  The OS has grown substantially over 
the years so that it is not the first choice for really resource 
constrained platforms any more.  But I am proud of the legacy of SDCC 
support and want to continue that support into the future.


NuttX has since graduated to an Apache incubator project and I am no 
long the "benevolent dictator"; nowadays I need negotiate changes.  No 
more banging my shoes on the table and demanding my way!


In order to work around the structure assignment limitation in the old 
SDCC, I had a special configuration option for SDCC called 
CONFIG_CAN_PASS_STRUCTS that conditioned the OS and made it possible to 
compile using the older SDCC versions.  There is a strong movement in 
the Apache NuttX project to remove that setting because it causes some 
obscure POSIX violations (and people think it is ugly).  Removing that 
option will break use of old SDCC version with the OS.


I have seen some references like 
https://github.com/z88dk/z88dk/issues/1132 that say, "Now that sdcc 
supports assigning structs,..."  So is this correct?  Does SDCC now 
properly support structure assignments?  How about things like the 
Linux-like mallinfo():


   struct mallinfo mallinfo(void);

Or the POSIX required sigqueue() function that passes a union:

   int  sigqueue(int pid, int signo, union sigval value);

It is likely that the special SDCC support will be removed.  If the 
current SDCC will support assignments and passing of structures and 
unions as parameters or return values, then there is no serious problem 
and can be handled with some updates to documentation.  If not, then we 
will lose all support for the z80 family.  The z80 itself is not such a 
viable platform for NuttX, but the z180 certainly is.


Please let me know so that I can provide proper advice or at least 
assess the damage.


Greg

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Nathan Hartman]

On Thu, Mar 19, 2020 at 10:45 AM Gregory Nutt  wrote:
> > (And, yes, we have to be very careful not to turn into a GCC-only,
> > ARM-only, Linux-only system.)
>
> That would have some short term gains, but would be suicide in the long run.

No short-term gains either. It would be a loss all around.

One of the *key* selling points of NuttX is that, *finally*, you can
develop an application for, say, a PIC32, and tomorrow run it on a
STM32, with minimal (if any) changes.

Until NuttX, it was difficult to port an application between two MCUs
from the same vendor, and practically impossible to port across
different vendors.

Nathan

Re: Build errors with inline functions

[John Rippetoe]

I'm using the generic arm-none-eabi toolchain, version 4.84.   OS is Ubuntu 
16.04.  The contents of my board Make.defs is below.  


# boards/arm/stm32h7/stm32h753xi-eval2/scripts/Make.defs
#
#   Copyright (C) 2018 Gregory Nutt. All rights reserved.
#   Author: Gregory Nutt 
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in
#the documentation and/or other materials provided with the
#distribution.
# 3. Neither the name NuttX nor the names of its contributors may be
#used to endorse or promote products derived from this software
#without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#


include ${TOPDIR}/.config
include ${TOPDIR}/tools/Config.mk
include ${TOPDIR}/arch/arm/src/armv7-m/Toolchain.defs

LDSCRIPT = flash.ld

ifeq ($(WINTOOL),y)
  # Windows-native toolchains
  DIRLINK = $(TOPDIR)/tools/copydir.sh
  DIRUNLINK = $(TOPDIR)/tools/unlink.sh
  MKDEP = $(TOPDIR)/tools/mkwindeps.sh
  ARCHINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}"
  ARCHXXINCLUDES = -I. -isystem "${shell cygpath -w $(TOPDIR)/include}" 
-isystem "${shell cygpath -w $(TOPDIR)/include/cxx}"
  ARCHSCRIPT = -T "${shell cygpath -w 
$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)}"
else
  # Linux/Cygwin-native toolchain
  MKDEP = $(TOPDIR)/tools/mkdeps$(HOSTEXEEXT)
  ARCHINCLUDES = -I. -isystem $(TOPDIR)/include
  ARCHXXINCLUDES = -I. -isystem $(TOPDIR)/include -isystem $(TOPDIR)/include/cxx
  ARCHSCRIPT = 
-T$(TOPDIR)/boards/$(CONFIG_ARCH)/$(CONFIG_ARCH_CHIP)/$(CONFIG_ARCH_BOARD)/scripts/$(LDSCRIPT)
endif

CC = $(CROSSDEV)gcc
CXX = $(CROSSDEV)g++
CPP = $(CROSSDEV)gcc -E
LD = $(CROSSDEV)ld
AR = $(ARCROSSDEV)ar rcs
NM = $(ARCROSSDEV)nm
OBJCOPY = $(CROSSDEV)objcopy
OBJDUMP = $(CROSSDEV)objdump

ARCHCCVERSION = ${shell $(CC) -v 2>&1 | sed -n '/^gcc version/p' | sed -e 
's/^gcc version \([0-9\.]\)/\1/g' -e 's/[-\ ].*//g' -e '1q'}
ARCHCCMAJOR = ${shell echo $(ARCHCCVERSION) | cut -d'.' -f1}

ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
  ARCHOPTIMIZATION = -g
endif

ifneq ($(CONFIG_DEBUG_NOOPT),y)
  ARCHOPTIMIZATION += $(MAXOPTIMIZATION) -fno-strict-aliasing 
-fno-strength-reduce -fomit-frame-pointer
endif

ARCHCFLAGS = -fno-builtin
ARCHCXXFLAGS = -fno-builtin -fno-exceptions -fcheck-new -fno-rtti
ARCHWARNINGS = -Wall -Wstrict-prototypes -Wshadow -Wundef
ARCHWARNINGSXX = -Wall -Wshadow -Wundef
ARCHDEFINES =
ARCHPICFLAGS = -fpic -msingle-pic-base -mpic-register=r10

CFLAGS = $(ARCHCFLAGS) $(ARCHWARNINGS) $(ARCHOPTIMIZATION) $(ARCHCPUFLAGS) 
$(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -pipe
CPICFLAGS = $(ARCHPICFLAGS) $(CFLAGS)
CXXFLAGS = $(ARCHCXXFLAGS) $(ARCHWARNINGSXX) $(ARCHOPTIMIZATION) 
$(ARCHCPUFLAGS) $(ARCHXXINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES) -pipe
CXXPICFLAGS = $(ARCHPICFLAGS) $(CXXFLAGS)
CPPFLAGS = $(ARCHINCLUDES) $(ARCHDEFINES) $(EXTRADEFINES)
AFLAGS = $(CFLAGS) -D__ASSEMBLY__

NXFLATLDFLAGS1 = -r -d -warn-common
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) 
-T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -no-check-sections
LDNXFLATFLAGS = -e main -s 2048

ASMEXT = .S
OBJEXT = .o
LIBEXT = .a
EXEEXT =

ifneq ($(CROSSDEV),arm-nuttx-elf-)
  LDFLAGS += -nostartfiles -nodefaultlibs
endif
ifeq ($(CONFIG_DEBUG_SYMBOLS),y)
  LDFLAGS += -g
endif


HOSTCC = gcc
HOSTINCLUDES = -I.
HOSTCFLAGS = -Wall -Wstrict-prototypes -Wshadow -Wundef -g -pipe
HOSTLDFLAGS =

John Rippetoe
Software Engineer
Robotic Research, LLC
(240) 631-0008

- Original Message -
From: "Nathan Hartman" 
To: dev@nuttx.apache.org
Sent: Thursday, March 19, 2020 10:39:39 AM
Subject: Re: Build errors with inline functions

On Thu, Mar 19, 2020 at 9:17 AM John Rippetoe
 wrote:
> I am working on a new board port for the STM32H7 that's not

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Gregory Nutt]

In addition to POSIX/ANSI/IEEE and LSB, NuttX is written to C89 (mostly).

However, as Greg points out, this particular (non-ANSI, non-C89)
interface comes to us from LSB. And if there is this interface, then
there are probably others.
The issue here is not C89.  C89 permits passing structures and unions.  
The issue here is the limitation of one toolchain that does not comply 
with C89 in this case.

For reasons like this, I think CONFIG_CAN_PASS_STRUCTS is a good compromise.
I think it is a reasonable compromise as well, but if SDCC has corrected 
their C89-compliance problem, then there would be no need to 
compromise.  We will need to look into that.. perhaps ask on the SDCC 
mail list: https://sourceforge.net/p/sdcc/mailman/sdcc-user/

That way, we can be:
o Loosely C89 except where being C89 interferes with other standards
o Strictly C89 at the cost of losing some compliance with other standards


Again, this is not a C89 issue.

The basic rules of the files are that within architecture- and 
board-specific code, people can follow most whatever C standard they 
prefer, but outside of the architecture- and board-specific code, we 
need to follow the lowest common denominator which is C89.



(And, yes, we have to be very careful not to turn into a GCC-only,
ARM-only, Linux-only system.)


That would have some short term gains, but would be suicide in the long run.

Greg

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Nathan Hartman]

On Thu, Mar 19, 2020 at 10:37 AM Gregory Nutt  wrote:
> mallinfo is not a strong argument, but sigqueue() is a better argument.

Yes, but like mallinfo, I'm sure we'll run into other cases where
changing the interface will result in having incompatible function
signatures to other standard systems (e.g., Linux).

I find it strange that after 21 years, more toolchains and software
projects haven't adopted C99. Twenty-one years!!

So, I would suggest to remain C89 compliant with the configurable
option to be either *strict* C89 (at the cost of losing some
standards-compliance with other stuff) or *loose* C89 (to gain better
standards-compliance with other stuff), the term "loose" meaning that
we can, for example, pass structs. But only if the user configures us
to do so.

Cheers,
Nathan

Re: Build errors with inline functions

[Nathan Hartman]

On Thu, Mar 19, 2020 at 9:17 AM John Rippetoe
 wrote:
> I am working on a new board port for the STM32H7 that's not yet in the
> repo. However, the same issue occurs when trying to build the existing
> H7 boards and with many of the F7 boards as well. All of the affected
> configs are flat builds, including my own.  The functions the compiler
> is complaining about are defined in up_mpu.c, which is only included for
> protected builds. So it makes sense you wouldn't see the issue when
> building in protected mode.
>
> To answer your other question: yes, I have done a clean build. I have
> also run a distclean and reconfigured, but the issue persists. The only
> way to get a build to complete is to comment out line 270 below from
> compiler.h
>
> /* GCC supports inlined functions for C++ and for C version C99 and above */
>
> 266   #  if defined(__cplusplus) || (defined(__STDC_VERSION__) &&
> __STDC_VERSION__ >= 199901L)
> 267   #define CONFIG_HAVE_INLINE 1
> 268   #  else
> 269   #undef CONFIG_HAVE_INLINE
> 270   #define inline
> 271   #  endif

Which toolchain are you using?

Which version of that toolchain?

What's in your board's Make.defs?

Cheers,
Nathan

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Gregory Nutt]

I suggest to remove CAN_PASS_STRUCTS not only because the code is
ulgy, the more important is that it break the 1st INVIOLABLES rule:
That is certainly a stronger argument.  Personal preference does not 
carry any weight.

Strict POSIX compliance
---

   o Strict conformance to the portable standard OS interface as defined at
 OpenGroup.org.
   o A deeply embedded system requires some special support.  Special
 support must be minimized.
   o The portable interface must never be compromised only for the sake of
 expediency.
   o Expediency or even improved performance are not justifications for
 violation of the strict POSIX interface

For example, we even change sigqueue prototype to work around the
compiler issue:
nuttx/include/signal.h:#ifdef CONFIG_CAN_PASS_STRUCTS
nuttx/include/signal.h-int  sigqueue(int pid, int signo, union sigval value);
nuttx/include/signal.h-#else
nuttx/include/signal.h-int  sigqueue(int pid, int signo, FAR void *sival_ptr);
nuttx/include/signal.h-#endif
It's great if we can support the noncompliant compiler without break
API prototype, but CONFIG_CAN_PASS_STRUCTS isn't a case.
BTW, SDCC dev fix this issue:
https://github.com/z88dk/z88dk/issues/1132


mallinfo is not a strong argument, but sigqueue() is a better argument.  
Z88DK is a different, but related compiler for the Z80 only.  It is not 
used by any NuttX platforms at present.  SDCC is here:  
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/


That Z88DK port does state that "Now that sdcc supports assigning 
structs, ..." implying that the real change is to SDCC.


There is an exception in the INVIOLABLES for deeplying embedded systems 
that could be invoked:


  o A deeply embedded system requires some special support.  Special support 
must be minimized.

Eliminating CONFIG_CAN_PASS_STRUCTS based on POSIX compliance is more 
palatable to me.  That is a much better argument that "Ugly" which is 
just a personal preference, something that we have to avoid.  We cannot 
make good engineering judgements based on personal preference.  What is 
important to one person, can be unimportant and "ugly" to another.

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Nathan Hartman]

On Thu, Mar 19, 2020 at 10:11 AM Gregory Nutt  wrote:
> > i'm not suggesting to remove SDCC support or whatever.
> > my proposal is the opposite.
> > always use the conservative prototype.
>
> There are a hieararchy of standards governing NuttX interfaces. The
> POSIX/ANSII/IEEE standard for a a Unix system as defined at
> OpenGroup.org.  And you are right, mallinfo is not specified there.
>
> But the second level of standards supported by NuttX are the Linux
> definitions.  It does have a Linux Standards Base (LSB), although its
> control is sloppy and permissive.  The form of mallinfo() is defined by
> that Linux specification as you can see with 'man mallinfo'

In addition to POSIX/ANSI/IEEE and LSB, NuttX is written to C89 (mostly).

However, as Greg points out, this particular (non-ANSI, non-C89)
interface comes to us from LSB. And if there is this interface, then
there are probably others.

For reasons like this, I think CONFIG_CAN_PASS_STRUCTS is a good compromise.

That way, we can be:
o Loosely C89 except where being C89 interferes with other standards
o Strictly C89 at the cost of losing some compliance with other standards

And most importantly, the end-user can choose which option is best for
the end-user's needs.

(And, yes, we have to be very careful not to turn into a GCC-only,
ARM-only, Linux-only system.)

Nathan

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Gregory Nutt]

i'm not suggesting to remove SDCC support or whatever.
my proposal is the opposite.
always use the conservative prototype.


There are a hieararchy of standards governing NuttX interfaces. The 
POSIX/ANSII/IEEE standard for a a Unix system as defined at 
OpenGroup.org.  And you are right, mallinfo is not specified there.


But the second level of standards supported by NuttX are the Linux 
definitions.  It does have a Linux Standards Base (LSB), although its 
control is sloppy and permissive.  The form of mallinfo() is defined by 
that Linux specification as you can see with 'man mallinfo'


I agree that it is a poorly designed interface, but I think it is 
required in its current form by the LSB.  Changing the function 
signature would certainly introduce very real compatibility issues and 
what what purpose?  For you personal preference?  That is not a 
sufficient reason.

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Xiang Xiao]

On Thu, Mar 19, 2020 at 9:12 PM Gregory Nutt  wrote:
>
>
> > depending on CONFIG_CAN_PASS_STRUCTS,
> > mallinfo has a different prototype.
> >
> > #ifdef CONFIG_CAN_PASS_STRUCTS
> > struct mallinfo mallinfo(void);
> > #else
> > int  mallinfo(FAR struct mallinfo *info);
> > #endif
> >
> > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > for this even in APPDIR.
> > i'd like to suggest to simplify this by always using
> > "int mallinfo(FAR struct mallinfo *info);" version.
> >
> > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > doesn't return any errors.
>
> We should not do that.  There are contemporary toolchains that do not
> support passing structures or unions.  Currently on the SDCC compiler
> cannot pass structures.  SDCC is one variant of similar compilers
> focusing on small MCUs.  I imagine that the others have similar
> limitations.  Currently SDCC is used only with z80 but there has been
> talk of using it with other architectures as well, but those have not
> gone anywhere.
>
> Certainly, removing support for SDCC and related compiles would close a
> lot of door for not reason other than your personal preference.  Certain
> the CONFIG_CAN_PASS_STRUCTS is ugly but it serves a real purpose for the
> community.  Your proposal serves no purpose other than you personal
> preference.
>
> It is worth re-considering the INVIOLABLES.txt which all committers are
> expected to uphold:
>
> All Users Matter
> 
>
>o All support must apply equally to all supported platforms.  At
> present
>  this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu,
>  Windows native, macOS, Solaris, and FreeBSD.  No tool/environment
>  solutions will be considered that limit the usage of NuttX on
> any of
>  the supported platforms.
>o Inclusive rather than exclusive.
>o *Hobbyists are valued users of the OS* including retro
> computing hobbyists
>  * and DIY “Maker” hobbyists.
>o Supported toolchains:  GCC, Clang, *SDCC*, ZiLOG ZDS-II (c89), IAR.
>  Others?
>o No changes to build system should limit use of NuttX by any user.
>o *Simplifying things for one user does not justify excluding
> another user.*
>o *We should seek to expand the NuttX user base, not to limit it
> for**
>  reasons of preference or priority.*
>o *We must resist the pull to make NuttX into a Linux-only,
> GCC-only, and**
>  ARM-only solution.*
>
> I think we must think less about ourselves and less about our own
> project environment, and more about the community.
>

I suggest to remove CAN_PASS_STRUCTS not only because the code is
ulgy, the more important is that it break the 1st INVIOLABLES rule:
Strict POSIX compliance
---

  o Strict conformance to the portable standard OS interface as defined at
OpenGroup.org.
  o A deeply embedded system requires some special support.  Special
support must be minimized.
  o The portable interface must never be compromised only for the sake of
expediency.
  o Expediency or even improved performance are not justifications for
violation of the strict POSIX interface

For example, we even change sigqueue prototype to work around the
compiler issue:
nuttx/include/signal.h:#ifdef CONFIG_CAN_PASS_STRUCTS
nuttx/include/signal.h-int  sigqueue(int pid, int signo, union sigval value);
nuttx/include/signal.h-#else
nuttx/include/signal.h-int  sigqueue(int pid, int signo, FAR void *sival_ptr);
nuttx/include/signal.h-#endif
It's great if we can support the noncompliant compiler without break
API prototype, but CONFIG_CAN_PASS_STRUCTS isn't a case.
BTW, SDCC dev fix this issue:
https://github.com/z88dk/z88dk/issues/1132

> Greg
>

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Takashi Yamamoto]

On Thu, Mar 19, 2020 at 10:12 PM Gregory Nutt  wrote:
>
>
> > depending on CONFIG_CAN_PASS_STRUCTS,
> > mallinfo has a different prototype.
> >
> > #ifdef CONFIG_CAN_PASS_STRUCTS
> > struct mallinfo mallinfo(void);
> > #else
> > int  mallinfo(FAR struct mallinfo *info);
> > #endif
> >
> > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > for this even in APPDIR.
> > i'd like to suggest to simplify this by always using
> > "int mallinfo(FAR struct mallinfo *info);" version.
> >
> > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > doesn't return any errors.
>
> We should not do that.  There are contemporary toolchains that do not
> support passing structures or unions.  Currently on the SDCC compiler
> cannot pass structures.  SDCC is one variant of similar compilers
> focusing on small MCUs.  I imagine that the others have similar
> limitations.  Currently SDCC is used only with z80 but there has been
> talk of using it with other architectures as well, but those have not
> gone anywhere.
>
> Certainly, removing support for SDCC and related compiles would close a
> lot of door for not reason other than your personal preference.  Certain
> the CONFIG_CAN_PASS_STRUCTS is ugly but it serves a real purpose for the
> community.  Your proposal serves no purpose other than you personal
> preference.

i'm not suggesting to remove SDCC support or whatever.
my proposal is the opposite.
always use the conservative prototype.

>
> It is worth re-considering the INVIOLABLES.txt which all committers are
> expected to uphold:
>
> All Users Matter
> 
>
>o All support must apply equally to all supported platforms.  At
> present
>  this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu,
>  Windows native, macOS, Solaris, and FreeBSD.  No tool/environment
>  solutions will be considered that limit the usage of NuttX on
> any of
>  the supported platforms.
>o Inclusive rather than exclusive.
>o *Hobbyists are valued users of the OS* including retro
> computing hobbyists
>  * and DIY “Maker” hobbyists.
>o Supported toolchains:  GCC, Clang, *SDCC*, ZiLOG ZDS-II (c89), IAR.
>  Others?
>o No changes to build system should limit use of NuttX by any user.
>o *Simplifying things for one user does not justify excluding
> another user.*
>o *We should seek to expand the NuttX user base, not to limit it
> for**
>  reasons of preference or priority.*
>o *We must resist the pull to make NuttX into a Linux-only,
> GCC-only, and**
>  ARM-only solution.*
>
> I think we must think less about ourselves and less about our own
> project environment, and more about the community.
>
> Greg
>

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Takashi Yamamoto]

On Thu, Mar 19, 2020 at 7:59 PM Xiang Xiao  wrote:
>
> On Thu, Mar 19, 2020 at 6:39 PM Takashi Yamamoto
>  wrote:
> >
> > do you feel the returning-structure version less uglier?
>
> Yes, returning-structure is a bad design in most case, but we can't
> change mallinfo prototype since it is defined by other OS:
> http://man7.org/linux/man-pages/man3/mallinfo.3.html

i wasn't aware of that implementation. thank you.
i'm skeptical about the usefulness of the compatibility with it though.
it's non-standard anyway.

>
> > my feeling is the opposite.
> > after all, it's a matter of taste i guess.
> >
>
> I mean the code contained #ifdef/#endif is more uglier than other.
> there are many place conditioned by CAN_PASS_STRUCTS, mallinfo is just
> one of case. It's better to fix all places instead.
>
> > On Thu, Mar 19, 2020 at 7:22 PM Xiang Xiao  
> > wrote:
> > >
> > > But, should we support the aged compiler to make the code ugly? I
> > > prefer to remove CAN_PASS_STRUCTS option and clean up the whole code
> > > base.
> > >
> > > On Thu, Mar 19, 2020 at 2:41 PM Takashi Yamamoto
> > >  wrote:
> > > >
> > > > hi,
> > > >
> > > > depending on CONFIG_CAN_PASS_STRUCTS,
> > > > mallinfo has a different prototype.
> > > >
> > > > #ifdef CONFIG_CAN_PASS_STRUCTS
> > > > struct mallinfo mallinfo(void);
> > > > #else
> > > > int  mallinfo(FAR struct mallinfo *info);
> > > > #endif
> > > >
> > > > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > > > for this even in APPDIR.
> > > > i'd like to suggest to simplify this by always using
> > > > "int mallinfo(FAR struct mallinfo *info);" version.
> > > >
> > > > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > > > doesn't return any errors.
> > > >
> > > > how do you think?

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Gregory Nutt]

But, should we support the aged compiler to make the code ugly? I
prefer to remove CAN_PASS_STRUCTS option and clean up the whole code
base.
That would be a blatant, self-serving violations of the principles of 
the INVIOLABLES which you agreed to support.


Another correction, SDCC is not an aged compiler.  It is a contemporary 
compiler with last release on January 30, 2020: 
https://en.wikipedia.org/wiki/Small_Device_C_Compiler  SDCCi s also 
closely related to the Z88DK which is probably seeing more use in small 
systems today:  https://en.wikipedia.org/wiki/Z88DK


"Ugly" is acceptable is if serves the NuttX community.  Selfish control 
of the OS for one businesses interest only is not acceptable.

Re: Build errors with inline functions

[John Rippetoe]

I am working on a new board port for the STM32H7 that's not yet in the 
repo. However, the same issue occurs when trying to build the existing 
H7 boards and with many of the F7 boards as well. All of the affected 
configs are flat builds, including my own.  The functions the compiler 
is complaining about are defined in up_mpu.c, which is only included for 
protected builds. So it makes sense you wouldn't see the issue when 
building in protected mode.


To answer your other question: yes, I have done a clean build. I have 
also run a distclean and reconfigured, but the issue persists. The only 
way to get a build to complete is to comment out line 270 below from 
compiler.h


/* GCC supports inlined functions for C++ and for C version C99 and above */

266   #  if defined(__cplusplus) || (defined(__STDC_VERSION__) && 
__STDC_VERSION__ >= 199901L)

267   #    define CONFIG_HAVE_INLINE 1
268   #  else
269   #    undef CONFIG_HAVE_INLINE
270   #    define inline
271   #  endif


Obviously this bypasses the check for C99 support being performed here.

- John

On 3/19/20 7:07 AM, Abdelatif Guettouche wrote:

Hi,

What config are you trying to build?
Did you try to run a clean build?

I built a couple of the protected mode STM32 boards, they all build
with no error.

On Wed, Mar 18, 2020 at 8:35 PM John Rippetoe
 wrote:

Hello,

I updated master on my repo yesterday and noticed that I can no longer
build STM32H7 or F7 based boards.  The compiler error in question is
shown below. For what its worth, I am using standard arm-none-eabi
toolchain on Ubuntu Linux.

LD: nuttx
nuttx/staging/libarch.a(stm32_allocateheap.o): In function
`mpu_configure_region':
nuttx/arch/arm/src/armv7-m/mpu.h:281: undefined reference to
`mpu_allocregion'
nuttx/arch/arm/src/armv7-m/mpu.h:296: undefined reference to
`mpu_log2regionceil'
nuttx/arch/arm/src/armv7-m/mpu.h:298: undefined reference to
`mpu_log2regionceil'
nuttx/arch/arm/src/armv7-m/mpu.h:315: undefined reference to `mpu_subregion'

These are all functions that are declared in arch/arm/src/armv7-m/mpu.h
and defined in arch/arm/src/armv7-m/up_mpu.c .  They are called within
various inlined functions defined in mpu.h.  The issue stems from a
change made by commit 3972510
,
where the logic for checking that inline functions are allowed was
changed to ensure the code is being compiled with at least the C99
standard.

I am still learning how the build system for NuttX is organized, so I
don't know exactly where to specify which C standard to use. Should this
be specified by the host system or be included as a flag in the build
files for affected chips? If it is the latter, I see two possible places
it could be added

  1. In the chip Make.defs
  2. In each board Make.defs, where the ARCHCFLAGS variable is already
 specified

Since this affects all boards with a particular chip, it seems better to
add it to the chip Make.defs. However, given that all the compiler flags
are currently specified at the board level, it seems better to put it
there for consistency's sake.

I'm not sure how many other chips are affected by this issue yet, but it
is presumably anything using inline functions.

Thanks,

John Rippetoe


CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.


CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
and privileged material for the sole use of the intended recipient. If you are 
not the intended recipient, please delete this e-mail and any attachments 
permanently.

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Gregory Nutt]

But, should we support the aged compiler to make the code ugly? I
prefer to remove CAN_PASS_STRUCTS option and clean up the whole code
base.
That would be a blatant, self-serving violations of the principles of 
the INVIOLABLES which you agreed to support.

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Gregory Nutt]

depending on CONFIG_CAN_PASS_STRUCTS,
mallinfo has a different prototype.

#ifdef CONFIG_CAN_PASS_STRUCTS
struct mallinfo mallinfo(void);
#else
int  mallinfo(FAR struct mallinfo *info);
#endif

and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
for this even in APPDIR.
i'd like to suggest to simplify this by always using
"int mallinfo(FAR struct mallinfo *info);" version.

or, even "void mallinfo(FAR struct mallinfo *info);" because it
doesn't return any errors.


We should not do that.  There are contemporary toolchains that do not 
support passing structures or unions.  Currently on the SDCC compiler 
cannot pass structures.  SDCC is one variant of similar compilers 
focusing on small MCUs.  I imagine that the others have similar 
limitations.  Currently SDCC is used only with z80 but there has been 
talk of using it with other architectures as well, but those have not 
gone anywhere.


Certainly, removing support for SDCC and related compiles would close a 
lot of door for not reason other than your personal preference.  Certain 
the CONFIG_CAN_PASS_STRUCTS is ugly but it serves a real purpose for the 
community.  Your proposal serves no purpose other than you personal 
preference.


It is worth re-considering the INVIOLABLES.txt which all committers are 
expected to uphold:


   All Users Matter
   

  o All support must apply equally to all supported platforms.  At
   present
    this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu,
    Windows native, macOS, Solaris, and FreeBSD.  No tool/environment
    solutions will be considered that limit the usage of NuttX on
   any of
    the supported platforms.
  o Inclusive rather than exclusive.
  o *Hobbyists are valued users of the OS* including retro
   computing hobbyists
    * and DIY “Maker” hobbyists.
  o Supported toolchains:  GCC, Clang, *SDCC*, ZiLOG ZDS-II (c89), IAR.
    Others?
  o No changes to build system should limit use of NuttX by any user.
  o *Simplifying things for one user does not justify excluding
   another user.*
  o *We should seek to expand the NuttX user base, not to limit it
   for**
    reasons of preference or priority.*
  o *We must resist the pull to make NuttX into a Linux-only,
   GCC-only, and**
    ARM-only solution.*

I think we must think less about ourselves and less about our own 
project environment, and more about the community.


Greg

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Xiang Xiao]

On Thu, Mar 19, 2020 at 6:39 PM Takashi Yamamoto
 wrote:
>
> do you feel the returning-structure version less uglier?

Yes, returning-structure is a bad design in most case, but we can't
change mallinfo prototype since it is defined by other OS:
http://man7.org/linux/man-pages/man3/mallinfo.3.html

> my feeling is the opposite.
> after all, it's a matter of taste i guess.
>

I mean the code contained #ifdef/#endif is more uglier than other.
there are many place conditioned by CAN_PASS_STRUCTS, mallinfo is just
one of case. It's better to fix all places instead.

> On Thu, Mar 19, 2020 at 7:22 PM Xiang Xiao  wrote:
> >
> > But, should we support the aged compiler to make the code ugly? I
> > prefer to remove CAN_PASS_STRUCTS option and clean up the whole code
> > base.
> >
> > On Thu, Mar 19, 2020 at 2:41 PM Takashi Yamamoto
> >  wrote:
> > >
> > > hi,
> > >
> > > depending on CONFIG_CAN_PASS_STRUCTS,
> > > mallinfo has a different prototype.
> > >
> > > #ifdef CONFIG_CAN_PASS_STRUCTS
> > > struct mallinfo mallinfo(void);
> > > #else
> > > int  mallinfo(FAR struct mallinfo *info);
> > > #endif
> > >
> > > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > > for this even in APPDIR.
> > > i'd like to suggest to simplify this by always using
> > > "int mallinfo(FAR struct mallinfo *info);" version.
> > >
> > > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > > doesn't return any errors.
> > >
> > > how do you think?

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Takashi Yamamoto]

do you feel the returning-structure version less uglier?
my feeling is the opposite.
after all, it's a matter of taste i guess.

On Thu, Mar 19, 2020 at 7:22 PM Xiang Xiao  wrote:
>
> But, should we support the aged compiler to make the code ugly? I
> prefer to remove CAN_PASS_STRUCTS option and clean up the whole code
> base.
>
> On Thu, Mar 19, 2020 at 2:41 PM Takashi Yamamoto
>  wrote:
> >
> > hi,
> >
> > depending on CONFIG_CAN_PASS_STRUCTS,
> > mallinfo has a different prototype.
> >
> > #ifdef CONFIG_CAN_PASS_STRUCTS
> > struct mallinfo mallinfo(void);
> > #else
> > int  mallinfo(FAR struct mallinfo *info);
> > #endif
> >
> > and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> > for this even in APPDIR.
> > i'd like to suggest to simplify this by always using
> > "int mallinfo(FAR struct mallinfo *info);" version.
> >
> > or, even "void mallinfo(FAR struct mallinfo *info);" because it
> > doesn't return any errors.
> >
> > how do you think?

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

[Xiang Xiao]

But, should we support the aged compiler to make the code ugly? I
prefer to remove CAN_PASS_STRUCTS option and clean up the whole code
base.

On Thu, Mar 19, 2020 at 2:41 PM Takashi Yamamoto
 wrote:
>
> hi,
>
> depending on CONFIG_CAN_PASS_STRUCTS,
> mallinfo has a different prototype.
>
> #ifdef CONFIG_CAN_PASS_STRUCTS
> struct mallinfo mallinfo(void);
> #else
> int  mallinfo(FAR struct mallinfo *info);
> #endif
>
> and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS
> for this even in APPDIR.
> i'd like to suggest to simplify this by always using
> "int mallinfo(FAR struct mallinfo *info);" version.
>
> or, even "void mallinfo(FAR struct mallinfo *info);" because it
> doesn't return any errors.
>
> how do you think?

Re: Build errors with inline functions

[Abdelatif Guettouche]

Hi,

What config are you trying to build?
Did you try to run a clean build?

I built a couple of the protected mode STM32 boards, they all build
with no error.

On Wed, Mar 18, 2020 at 8:35 PM John Rippetoe
 wrote:
>
> Hello,
>
> I updated master on my repo yesterday and noticed that I can no longer
> build STM32H7 or F7 based boards.  The compiler error in question is
> shown below. For what its worth, I am using standard arm-none-eabi
> toolchain on Ubuntu Linux.
>
> LD: nuttx
> nuttx/staging/libarch.a(stm32_allocateheap.o): In function
> `mpu_configure_region':
> nuttx/arch/arm/src/armv7-m/mpu.h:281: undefined reference to
> `mpu_allocregion'
> nuttx/arch/arm/src/armv7-m/mpu.h:296: undefined reference to
> `mpu_log2regionceil'
> nuttx/arch/arm/src/armv7-m/mpu.h:298: undefined reference to
> `mpu_log2regionceil'
> nuttx/arch/arm/src/armv7-m/mpu.h:315: undefined reference to `mpu_subregion'
>
> These are all functions that are declared in arch/arm/src/armv7-m/mpu.h
> and defined in arch/arm/src/armv7-m/up_mpu.c .  They are called within
> various inlined functions defined in mpu.h.  The issue stems from a
> change made by commit 3972510
> ,
> where the logic for checking that inline functions are allowed was
> changed to ensure the code is being compiled with at least the C99
> standard.
>
> I am still learning how the build system for NuttX is organized, so I
> don't know exactly where to specify which C standard to use. Should this
> be specified by the host system or be included as a flag in the build
> files for affected chips? If it is the latter, I see two possible places
> it could be added
>
>  1. In the chip Make.defs
>  2. In each board Make.defs, where the ARCHCFLAGS variable is already
> specified
>
> Since this affects all boards with a particular chip, it seems better to
> add it to the chip Make.defs. However, given that all the compiler flags
> are currently specified at the board level, it seems better to put it
> there for consistency's sake.
>
> I'm not sure how many other chips are affected by this issue yet, but it
> is presumably anything using inline functions.
>
> Thanks,
>
> John Rippetoe
>
>
> CONFIDENTIALITY NOTICE: This communication may contain private, confidential 
> and privileged material for the sole use of the intended recipient. If you 
> are not the intended recipient, please delete this e-mail and any attachments 
> permanently.
>