Trouble creating RSB Package: error copying tree
Hi Devel, I've been working on porting CANFestival to RTEMS. I ended up creating some changes to CANFestival to allow it to be built against an RTEMS BSP. All was going well except a strange ldconfig error, when I tried to fix it by removing the build directory (rtems_source_builder/rtems/build). Now I get the following error: error: copying tree: /other/rtems/rtems-source-builder/rtems/build/tmp/canfestival-8bfe0ac00cdb-arm-rtems4.11-1-root-isaac.gutekunst - /other/rtems/rtems-source-builder/rtems/build/tmp/sb-isaac.gutekunst/4.11/net/canfestival: [Errno 2] No such file or directory: '/other/rtems/rtems-source-builder/rtems/build/tmp/canfestival-8bfe0ac00cdb-arm-rtems4.11-1-root-isaac.gutekunst' I tried re-building ntp, the package I based my bset and cfg files off of, and it doesn't build correctly, but gets much farther along. Any idea what's going on ? Thanks, Isaac -- Isaac Gutekunst Embedded Systems Software Engineer isaac.guteku...@vecna.com www.vecna.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
ARMv7M Exception Handler
Hey guys, I was working on the exception handler for the CPU hard fault. Managed to register the fatal error user extension to RTEMS and call the user defined function when an exception occurs. But the pointer to the stacked frame didn't have the correct register values(esp. the PC register). So I looked into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c, where it decides which stack pointer was used (MSP or PSP) before the exception occurred depending on the error code returned in the Link Register. After carefully examining all the assembly instructions, I guess theres a little bug in the code. The instruction cmn r2, #3\n in line 31 basically compares the Link Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS and compares with LHS) and chooses MSP or PSP in the following IT block. This is pretty cool! But, it will not work if you have the floating-point unit (FPU) enabled in your processor, which is enabled in mine. With FPU enabled, the error code returned is either 0xFFE9 or 0xFFED, for which the above assembly instruction will not work out and MSP will be selected always. Better way to do is to check the 2nd bit of the error code to determine which stack pointer was used before the exception happened - tst lr, #4\n and change the IT block from itt ne to itt eq and the mov and add within this IT block. Have tested this with the above changes and it works. I have sent the patch 0001-Fix-exception-handler-for-supporting-FPU.patch to the devel mailing list that fixes this problem. :) Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] RTEMS CAN Rough Draft Implementation
Hi All,
Here is the RTEMS CAN driver framework I've been talking about. Please
give me feedback, and don't worry about being harsh. I want to commit
something of value.
Concerns
* Usage of return codes.
* General higher level error handling.
* Changing can bit rate.
* In general, changing CAN parameters at runtime.
* Task model: Should there really be an RX and TX task required by the
RTEMS driver? Is the method of starting and stopping tasks acceptable?
The motivation for this is that the CAN controller we are using, (STM32
BxCAN) requires you to re-initialize the device to change parameters.
This is a bit awkward with first calling open, and then IOCTL to
configure the bus. Any thoughts?
Thanks,
Isaac
P.S. I'm having trouble with git send-email. Something is not quite
right with our mail server here. I've attached the patch instead.
--
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.guteku...@vecna.com
www.vecna.com
From a151795883f68dbff91d3044bbf8d629b4b6996f Mon Sep 17 00:00:00 2001
From: Isaac Gutekunst isaac.guteku...@vecna.com
Date: Mon, 24 Aug 2015 09:45:27 -0400
Subject: [PATCH] cpukit: Create CAN Driver framework
---
cpukit/dev/Makefile.am| 6 +
cpukit/dev/can/can.c | 510 ++
cpukit/dev/include/dev/can/can-internal.h | 208
cpukit/dev/include/dev/can/can.h | 86 +
cpukit/dev/preinstall.am | 13 +
cpukit/score/cpu/arm/rtems/score/cpu.h| 2 +-
6 files changed, 824 insertions(+), 1 deletion(-)
create mode 100644 cpukit/dev/can/can.c
create mode 100644 cpukit/dev/include/dev/can/can-internal.h
create mode 100644 cpukit/dev/include/dev/can/can.h
diff --git a/cpukit/dev/Makefile.am b/cpukit/dev/Makefile.am
index 47a1585..cffcf25 100644
--- a/cpukit/dev/Makefile.am
+++ b/cpukit/dev/Makefile.am
@@ -11,6 +11,11 @@ include_dev_i2c_HEADERS += include/dev/i2c/gpio-nxp-pca9535.h
include_dev_i2c_HEADERS += include/dev/i2c/i2c.h
include_dev_i2c_HEADERS += include/dev/i2c/switch-nxp-pca9548a.h
+include_dev_candir = $(includedir)/dev/can
+include_dev_can_HEADERS =
+include_dev_can_HEADERS += include/dev/can/can.h
+include_dev_can_HEADERS += include/dev/can/can-internal.h
+
include_linuxdir = $(includedir)/linux
include_linux_HEADERS =
include_linux_HEADERS += include/linux/i2c.h
@@ -24,6 +29,7 @@ libdev_a_SOURCES += i2c/gpio-nxp-pca9535.c
libdev_a_SOURCES += i2c/i2c-bus.c
libdev_a_SOURCES += i2c/i2c-dev.c
libdev_a_SOURCES += i2c/switch-nxp-pca9548a.c
+libdev_a_SOURCES += can/can.c
include $(srcdir)/preinstall.am
include $(top_srcdir)/automake/local.am
diff --git a/cpukit/dev/can/can.c b/cpukit/dev/can/can.c
new file mode 100644
index 000..2610498
--- /dev/null
+++ b/cpukit/dev/can/can.c
@@ -0,0 +1,510 @@
+/**
+ * @file can.c
+ *
+ * @ingroup can
+ * @brief Control Area Network (can) Driver API
+ *
+ * @brief RTEMS can driver. Exposes a posix interface to the can bus
+ * similar to lincan.
+ *
+ */
+
+/*
+ * Copyright (c) 2015 Vecna Technologies, Inc.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.com/license/LICENSE.
+ */
+
+
+#if HAVE_CONFIG_H
+ #include config.h
+#endif
+
+#include dev/can/can-internal.h
+
+
+#include rtems/imfs.h
+
+#include stdlib.h
+#include string.h
+#include stdbool.h
+#include fcntl.h
+
+#define CAN_QUEUE_LEN 10
+#define CAN_TASK_PRIORITY 70
+
+static bool free_busses[10] = {true};
+
+int get_free_bus_number(
+ void
+)
+{
+ int i;
+ for (i = 1; i 10; i++) {
+if (true == free_busses[i]) {
+ free_busses[i] = false;
+ return i;
+}
+ }
+ return -1;
+}
+
+void can_bus_obtain(can_bus *bus)
+{
+ rtems_status_code sc;
+
+ sc = rtems_semaphore_obtain(bus-mutex, RTEMS_WAIT, RTEMS_NO_TIMEOUT);
+ _Assert(sc == RTEMS_SUCCESSFUL);
+ (void) sc;
+}
+
+void can_bus_release(can_bus *bus)
+{
+ rtems_status_code sc;
+
+ sc = rtems_semaphore_release(bus-mutex);
+ _Assert(sc == RTEMS_SUCCESSFUL);
+ (void) sc;
+}
+
+int can_bus_change_baudrate(
+ can_bus * bus,
+ uint32_t baud
+)
+{
+ can_bus_obtain(bus);
+ bus-de_init(bus);
+ bus-init(bus, baud);
+ can_bus_release(bus);
+ return 0;
+}
+
+int can_bus_set_filter(
+ can_bus * bus,
+ can_filter * filter
+)
+{
+ int err;
+ _Assert(filter);
+ can_bus_obtain(bus);
+ err = bus-set_filter(bus, filter);
+ can_bus_release(bus);
+ return err;
+}
+
+
+int can_bus_init_default(
+ can_bus * bus,
+ long baud
+)
+{
+ (void) bus;
+ (void) baud;
+ return 0;
+ return -EIO;
+}
+
+int can_bus_de_init_default(
+ can_bus * bus
+)
+{
+ (void) bus;
+ return -EIO;
+}
+
+int can_bus_set_filter_default(
+ can_bus * bus,
+ can_filter * filter
+)
+{
+ (void) bus;
+ (void) filter;
+ return -EIO;
+}
+int can_bus_get_num_filters_default(
+ can_bus * bus
+)
+{
+ (void) bus;
+ return -EIO;
+}
+
+int can_bus_transfer(can_bus *bus, can_msg
Re: cppcheck errors
On 8/13/2015 10:52 AM, Daniel Gutson wrote: El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu mailto:ged...@gwu.edu escribió: Daniel, Unknown deadline right now. Probably whenever Joel can get around to it! Realistically, we can create a bugfix dot release anytime after the release subject to user demand. So, even if you miss the 4.11.0 release with your patches, we can cut a 4.11.1 after applying the patches if you need an official release to work from. Ok. Yes, we do. Thanks. Anyway we're making a ranking for a timebox of 2 weeks. Any updates? Gedare On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson daniel.gut...@tallertechnologies.com mailto:daniel.gut...@tallertechnologies.com wrote: Hi Gedare, What's the deadline for the official release, if any? El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu mailto:ged...@gwu.edu escribió: Daniel, The release has (unofficially) happened on rtems.git/4.11 branch, from which master is slowly diverging. Any patches you want applied before the official release need to be (1) associated with a ticket on Trac, and (2) apply to both the 4.11 and master branches. Gedare On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson daniel.gut...@tallertechnologies.com mailto:daniel.gut...@tallertechnologies.com wrote: Hi guys, we will be posting patches for a number of errors reported by cppcheck (errors that we can confirm are not false positives). Please hold on any release. Daniel. -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype:dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson ___ devel mailing list devel@rtems.org mailto:devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: ARMv7M Exception Handler
On 8/27/2015 3:58 PM, Daniel Gutson wrote: On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan sudarshan.rajagopa...@vecna.com wrote: Hey guys, I was working on the exception handler for the CPU hard fault. Managed to register the fatal error user extension to RTEMS and call the user defined function when an exception occurs. But the pointer to the stacked frame didn't have the correct register values(esp. the PC register). So I looked into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c, where it decides which stack pointer was used (MSP or PSP) before the exception occurred depending on the error code returned in the Link Register. After carefully examining all the assembly instructions, I guess theres a little bug in the code. The instruction cmn r2, #3\n in line 31 basically compares the Link Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS and compares with LHS) and chooses MSP or PSP in the following IT block. This is pretty cool! But, it will not work if you have the floating-point unit (FPU) enabled in your processor, which is enabled in mine. With FPU enabled, the error code returned is either 0xFFE9 or 0xFFED, for which the above assembly instruction will not work out and MSP will be selected always. Better way to do is to check the 2nd bit of the error code to determine which stack pointer was used before the exception happened - tst lr, #4\n and change the IT block from itt ne to itt eq and the mov and add within this IT block. Have tested this with the above changes and it works. I have sent the patch 0001-Fix-exception-handler-for-supporting-FPU.patch to the devel mailing list that fixes this problem. :) Nice. Have you tested this without FPU support too? Daniel .. when you are happy, we can push it. Should this go on the 4.11 branch and master? If so, it needs a ticket. Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Fix exception handler for supporting FPU
Patch attached here for ARMv7M Exception Handler. [1] Looks like git
send-email didn't deliver the mail. Something is not quite right with
our mail server here. Avoid this email if patch delivered through git.
Thanks and Regards,
Sudarshan
Links:
--
[1] https://lists.rtems.org/pipermail/devel/2015-August/012381.html
From e7674a2c26a3db26e3019f3c6ee94c9ea88d5a3c Mon Sep 17 00:00:00 2001
From: Sudarshan Rajagopalan sudarshan.rajagopa...@vecna.com
Date: Thu, 27 Aug 2015 14:19:24 -0400
Subject: [PATCH] Fix exception handler for supporting FPU
---
cpukit/score/cpu/arm/armv7m-exception-default.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpukit/score/cpu/arm/armv7m-exception-default.c
b/cpukit/score/cpu/arm/armv7m-exception-default.c
index e890cdf..2ddc6fc 100644
--- a/cpukit/score/cpu/arm/armv7m-exception-default.c
+++ b/cpukit/score/cpu/arm/armv7m-exception-default.c
@@ -28,10 +28,10 @@ void __attribute__((naked)) _ARMV7M_Exception_default( void
)
mov r2, lr\n
mrs r1, msp\n
mrs r0, psp\n
-cmn r2, #3\n
-itt ne\n
-movne r0, r1\n
-addne r0, %[cpufsz]\n
+tst lr, #4\n
+itt eq\n
+moveq r0, r1\n
+addeq r0, %[cpufsz]\n
add r2, r0, %[v7mlroff]\n
add r1, sp, %[cpulroff]\n
ldm r2, {r3-r5}\n
--
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: cppcheck errors
On Thu, Aug 27, 2015 at 6:19 PM, Daniel Gutson daniel.gut...@tallertechnologies.com wrote: Please note too that there are some false positives, like the realloc one. Actually, we ruled out most false positives. IIRC that one is an actual bug. Btw, sorry for the Spanish comment there. It means that if we don't initialize _ccr we just get a #warning, but the actual problem remains. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: ARMv7M Exception Handler
On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan sudarshan.rajagopa...@vecna.com wrote: Hey guys, I was working on the exception handler for the CPU hard fault. Managed to register the fatal error user extension to RTEMS and call the user defined function when an exception occurs. But the pointer to the stacked frame didn't have the correct register values(esp. the PC register). So I looked into the assembly code in /cpukit/score/cpu/arm/armv7m-exception-default.c, where it decides which stack pointer was used (MSP or PSP) before the exception occurred depending on the error code returned in the Link Register. After carefully examining all the assembly instructions, I guess theres a little bug in the code. The instruction cmn r2, #3\n in line 31 basically compares the Link Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS and compares with LHS) and chooses MSP or PSP in the following IT block. This is pretty cool! But, it will not work if you have the floating-point unit (FPU) enabled in your processor, which is enabled in mine. With FPU enabled, the error code returned is either 0xFFE9 or 0xFFED, for which the above assembly instruction will not work out and MSP will be selected always. Better way to do is to check the 2nd bit of the error code to determine which stack pointer was used before the exception happened - tst lr, #4\n and change the IT block from itt ne to itt eq and the mov and add within this IT block. Have tested this with the above changes and it works. I have sent the patch 0001-Fix-exception-handler-for-supporting-FPU.patch to the devel mailing list that fixes this problem. :) Nice. Have you tested this without FPU support too? Thanks and Regards, Sudarshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype:dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: cppcheck errors
On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
Maybe we can just provide the list until we provide the fixes? Martín?
Gladly. Keep in mind we ran cppcheck only on the modules we use
(though some things may've slipped in, like nios):
[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of
character ({) when these macros are defined: '__cplusplus'.
[cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
[cpukit/libmisc/dumpbuf/dumpbuf.c:76]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
[cpukit/libmisc/stackchk/check.c:285] -
[cpukit/libmisc/stackchk/check.c:294]: (performance) Variable
'pattern_ok' is reassigned a value before the old one has been used.
[cpukit/libmisc/stackchk/check.c:255]: (portability) 'pattern_area' is
of type 'void *'. When using void pointers in calculations, the
behaviour is undefined.
[cpukit/libnetworking/kern/kern_subr.c:93]: (portability) 'cp' is of
type 'void *'. When using void pointers in calculations, the behaviour
is undefined.
[cpukit/libnetworking/kern/uipc_socket2.c:616]: (error) Uninitialized
variable: o
[cpukit/libnetworking/lib/ftpfs.c:704] -
[cpukit/libnetworking/lib/ftpfs.c:709]: (performance) Variable
'port_socket' is reassigned a value before the old one has been used.
[cpukit/libnetworking/lib/tftpDriver.c:503]: (error) Common realloc
mistake: 'current' nulled but not freed upon failure
[cpukit/libnetworking/libc/ether_addr.c:72]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/ether_addr.c:94]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/gethostbyht.c:233]: (error) Common realloc
mistake: 'hostmap' nulled but not freed upon failure
[cpukit/libnetworking/libc/ns_addr.c:112]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:120]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:128]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:137]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc
mistake: 'dhcp_hostname' nulled but not freed upon failure
[cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd
[cpukit/posix/include/rtems/posix/ptimer.h:33]: (error) Invalid number
of character ({) when these macros are defined: '__cplusplus'.
[cpukit/rtems/include/rtems/rtems/dpmemimpl.h:116]: (error) Invalid
number of character ({) when these macros are defined: '__cplusplus'.
[cpukit/score/cpu/h8300/cpu.c:54]: (error) Uninitialized variable:
_ccr (si no se inicializa, se hace un #warning pero igual existe el
problema)
[cpukit/zlib/gzwrite.c:80]: (error) Uninitialized variable: got
[tools/build/binpatch.c:104]: (error) Resource leak: ifp
[tools/build/binpatch.c:63]: (error) Uninitialized variable: off
[tools/build/unhex.c:238]: (error) Resource leak: outfp
[tools/cpu/nios2/memory.c:99]: (error) Uninitialized variable: memory
[tools/cpu/nios2/ptf.c:542]: (error) fprintf format string has 1
parameters but only 0 are given.
[tools/cpu/nios2/ptf.c:580]: (error) Memory leak: new_prefix
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: cppcheck errors
On 8/27/2015 4:10 PM, Daniel Gutson wrote: On Thu, Aug 27, 2015 at 6:06 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 8/13/2015 10:52 AM, Daniel Gutson wrote: El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu mailto:ged...@gwu.edu escribió: Daniel, Unknown deadline right now. Probably whenever Joel can get around to it! Realistically, we can create a bugfix dot release anytime after the release subject to user demand. So, even if you miss the 4.11.0 release with your patches, we can cut a 4.11.1 after applying the patches if you need an official release to work from. Ok. Yes, we do. Thanks. Anyway we're making a ranking for a timebox of 2 weeks. Any updates? Sorry guys, we have a release tomorrow (which contains some of the top fixes) but didn't have the time to send a patch. We will send it early next week. FWIW, nios had memory leaks but since we are not using that arch we skipped it. Maybe we can just provide the list until we provide the fixes? Martín? Both Sebastian and Chris are on holiday this week so there is no reason to rush. Posting a list of issues would be good but it may have to be pinged when they are back on line. I know Chris has experience with the NIOS so he will want to review those. --joel Gedare On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson daniel.gut...@tallertechnologies.com mailto:daniel.gut...@tallertechnologies.com wrote: Hi Gedare, What's the deadline for the official release, if any? El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu mailto:ged...@gwu.edu escribió: Daniel, The release has (unofficially) happened on rtems.git/4.11 branch, from which master is slowly diverging. Any patches you want applied before the official release need to be (1) associated with a ticket on Trac, and (2) apply to both the 4.11 and master branches. Gedare On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson daniel.gut...@tallertechnologies.com mailto:daniel.gut...@tallertechnologies.com wrote: Hi guys, we will be posting patches for a number of errors reported by cppcheck (errors that we can confirm are not false positives). Please hold on any release. Daniel. -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype:dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson ___ devel mailing list devel@rtems.org mailto:devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: cppcheck errors
On 8/27/2015 4:15 PM, Martin Galvan wrote:
On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
daniel.gut...@tallertechnologies.com wrote:
Maybe we can just provide the list until we provide the fixes? Martín?
Gladly. Keep in mind we ran cppcheck only on the modules we use
(though some things may've slipped in, like nios):
Most of these are worth looking at. Honestly, the ones on the tcp/ip
stack and other directly imported code aren't going to get touched.
[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of
character ({) when these macros are defined: '__cplusplus'.
Spot check shows this is missing the closing magic for extern C.
I see a couple more of these below and we should fix though.
[cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
[cpukit/libmisc/dumpbuf/dumpbuf.c:76]: (error) Undefined behavior:
Variable 'line_buffer' is used as parameter and destination in
s[n]printf().
This should be looked at.
[cpukit/libmisc/stackchk/check.c:285] -
[cpukit/libmisc/stackchk/check.c:294]: (performance) Variable
'pattern_ok' is reassigned a value before the old one has been used.
This should be looked at.
[cpukit/libmisc/stackchk/check.c:255]: (portability) 'pattern_area' is
of type 'void *'. When using void pointers in calculations, the
behaviour is undefined.
Not sure what to do about this. I think this is defined behavior
for at least GCC.
[cpukit/libnetworking/kern/kern_subr.c:93]: (portability) 'cp' is of
type 'void *'. When using void pointers in calculations, the behaviour
is undefined.
[cpukit/libnetworking/kern/uipc_socket2.c:616]: (error) Uninitialized
variable: o
Imported code.
[cpukit/libnetworking/lib/ftpfs.c:704] -
[cpukit/libnetworking/lib/ftpfs.c:709]: (performance) Variable
'port_socket' is reassigned a value before the old one has been used.
[cpukit/libnetworking/lib/tftpDriver.c:503]: (error) Common realloc
mistake: 'current' nulled but not freed upon failure
Need to be looked at.
[cpukit/libnetworking/libc/ether_addr.c:72]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/ether_addr.c:94]: (portability) scanf
without field width limits can crash with huge input data on some
versions of libc.
[cpukit/libnetworking/libc/gethostbyht.c:233]: (error) Common realloc
mistake: 'hostmap' nulled but not freed upon failure
[cpukit/libnetworking/libc/ns_addr.c:112]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:120]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:128]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
[cpukit/libnetworking/libc/ns_addr.c:137]: (portability) scanf without
field width limits can crash with huge input data on some versions of
libc.
All imported code. maybe the realloc() is worth addressing.
[cpukit/libnetworking/rtems/rtems_dhcp.c:401]: (error) Common realloc
mistake: 'dhcp_hostname' nulled but not freed upon failure
This is the only one in our code.
[cpukit/librpc/src/rpc/netnamer.c:331]: (error) Resource leak: fd
Probably should be looked at.
[cpukit/posix/include/rtems/posix/ptimer.h:33]: (error) Invalid number
of character ({) when these macros are defined: '__cplusplus'.
[cpukit/rtems/include/rtems/rtems/dpmemimpl.h:116]: (error) Invalid
number of character ({) when these macros are defined: '__cplusplus'.
Easy.
[cpukit/score/cpu/h8300/cpu.c:54]: (error) Uninitialized variable:
_ccr (si no se inicializa, se hace un #warning pero igual existe el
problema)
Appears to be confused by conditional or inline asm.
[cpukit/zlib/gzwrite.c:80]: (error) Uninitialized variable: got
Hmm.. but third party code.
[tools/build/binpatch.c:104]: (error) Resource leak: ifp
[tools/build/binpatch.c:63]: (error) Uninitialized variable: off
[tools/build/unhex.c:238]: (error) Resource leak: outfp
Need to be looked at but these are host side utilities. There is likely
no resource leak since it is a process. The unitialized variable needs
looking at. We fixed a number of issues flagged by CodeSonar in these
last year.
[tools/cpu/nios2/memory.c:99]: (error) Uninitialized variable: memory
[tools/cpu/nios2/ptf.c:542]: (error) fprintf format string has 1
parameters but only 0 are given.
[tools/cpu/nios2/ptf.c:580]: (error) Memory leak: new_prefix
Those worth a look. But again a host-side utility.
--
Joel Sherrill, Ph.D. Director of Research Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
___
devel mailing list
devel@rtems.org
obsolete m32r port
Hi Another one on my chopping block. I don't see the official not recommended for new designs language but I also don't seen much hinting an update in five years either. http://am.renesas.com/products/mpumcu/m32r/index.jsp Anyone got any thoughts about it being a part that is still being sold and we should support it? Again, mark it as deprecated in the 4.11 notes and remove it on master if no one objects. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: cppcheck errors
On Thu, Aug 27, 2015 at 6:06 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 8/13/2015 10:52 AM, Daniel Gutson wrote: El 13/8/2015 12:49, Gedare Bloom ged...@gwu.edu mailto:ged...@gwu.edu escribió: Daniel, Unknown deadline right now. Probably whenever Joel can get around to it! Realistically, we can create a bugfix dot release anytime after the release subject to user demand. So, even if you miss the 4.11.0 release with your patches, we can cut a 4.11.1 after applying the patches if you need an official release to work from. Ok. Yes, we do. Thanks. Anyway we're making a ranking for a timebox of 2 weeks. Any updates? Sorry guys, we have a release tomorrow (which contains some of the top fixes) but didn't have the time to send a patch. We will send it early next week. FWIW, nios had memory leaks but since we are not using that arch we skipped it. Maybe we can just provide the list until we provide the fixes? Martín? Gedare On Thu, Aug 13, 2015 at 11:18 AM, Daniel Gutson daniel.gut...@tallertechnologies.com mailto:daniel.gut...@tallertechnologies.com wrote: Hi Gedare, What's the deadline for the official release, if any? El 13/8/2015 7:15, Gedare Bloom ged...@gwu.edu mailto:ged...@gwu.edu escribió: Daniel, The release has (unofficially) happened on rtems.git/4.11 branch, from which master is slowly diverging. Any patches you want applied before the official release need to be (1) associated with a ticket on Trac, and (2) apply to both the 4.11 and master branches. Gedare On Wed, Aug 12, 2015 at 5:43 PM, Daniel Gutson daniel.gut...@tallertechnologies.com mailto:daniel.gut...@tallertechnologies.com wrote: Hi guys, we will be posting patches for a number of errors reported by cppcheck (errors that we can confirm are not false positives). Please hold on any release. Daniel. -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype:dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson ___ devel mailing list devel@rtems.org mailto:devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo 47, 3rd Floor, Office 5 Córdoba, Argentina Phone: +54 351 4217888 / +54 351 4218211 Skype:dgutson LinkedIn: http://ar.linkedin.com/in/danielgutson ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
obsolete h8300 was Re: cppcheck errors
On 8/27/2015 4:22 PM, Martin Galvan wrote: On Thu, Aug 27, 2015 at 6:19 PM, Daniel Gutson daniel.gut...@tallertechnologies.com wrote: Please note too that there are some false positives, like the realloc one. Actually, we ruled out most false positives. IIRC that one is an actual bug. Btw, sorry for the Spanish comment there. It means that if we don't initialize _ccr we just get a #warning, but the actual problem remains. The h8 port is up for discussion to be deprecated. As best I can tell most, if not all, of the models we support are not recommended for new designs. I think the entire h8300 family is in that situation. The h8sx and h8s are the only viable parts of the family left. I wanted to start deprecation discussions now that we are past branching 4.11. :) My intention would be to announce ports and BSPs as deprecated in 4.11 and remove them from the master to reduce our work going forward. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
