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

See Changes: -- [...truncated 505.64 KB...] Configuration/Tool: sim/dsptest ---

Re: problem with nxsig_timeout (sig_timedwait.c)

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

Re: problem with nxsig_timeout (sig_timedwait.c)

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

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

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 A

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

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

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

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

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

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

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

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

Podling Nuttx Report Reminder - April 2020

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

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

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

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

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 accor

Re: Build errors with inline functions

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

problem with nxsig_timeout (sig_timedwait.c)

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

Re: Build errors with inline functions

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 wor

Re: Build errors with inline functions

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 alwa

Re: Build errors with inline functions

-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 a

Re: Build errors with inline functions

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 al

Re: Build errors with inline functions

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

Re: Build errors with inline functions

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 te

Re: Build errors with inline functions

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 nucl

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.

Fwd: State of Structure Assignments

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.

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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.

Re: Build errors with inline functions

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

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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

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 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,

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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 Un

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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, malli

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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 w

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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

Re: Build errors with inline functions

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 complaini

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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

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 t

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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 cl

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

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 C

Re: Build errors with inline functions

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 longe