Re: On Master All GDB Builds Fail on Cygwin

On 14/10/20 11:45 am, Joel Sherrill wrote: > On Tue, Oct 13, 2020, 6:37 PM Chris Johns > wrote: > > On 14/10/20 9:42 am, Joel Sherrill wrote: > > Finally got an answer from Corinna and she said to report this to gdb. > But > when > > I went to repeat it,

Re: On Master All GDB Builds Fail on Cygwin

On 14/10/2020 02:45, Joel Sherrill wrote: On Tue, Oct 13, 2020, 6:37 PM Chris Johns > wrote: On 14/10/20 9:42 am, Joel Sherrill wrote: > Finally got an answer from Corinna and she said to report this to gdb. But when > I went to repeat it, it builds now.

Re: On Master All GDB Builds Fail on Cygwin

On Tue, Oct 13, 2020, 6:37 PM Chris Johns wrote: > On 14/10/20 9:42 am, Joel Sherrill wrote: > > Finally got an answer from Corinna and she said to report this to gdb. > But when > > I went to repeat it, it builds now. > > Weird. Was Cygwin updated? > No. Sebastian bumped the head of gdb. > > >

Re: On Master All GDB Builds Fail on Cygwin

On 14/10/20 9:42 am, Joel Sherrill wrote: > Finally got an answer from Corinna and she said to report this to gdb. But > when > I went to repeat it, it builds now. Weird. Was Cygwin updated? > Unfortunately, the source builder ended with this on Cygwin. A Linux VM on the > same physical computer

Sentinel-6 and RTEMS??

Hi I noticed this is scheduled to launch Nov 10. Per the ESA mission description and the organizations involved, I expect there is at least one RTEMS-based instrument or subsystem in it. https://sentinel.esa.int/web/sentinel/missions/sentinel-6/mission-summary The Star Tracker has no provider an

Re: On Master All GDB Builds Fail on Cygwin

Finally got an answer from Corinna and she said to report this to gdb. But when I went to repeat it, it builds now. Unfortunately, the source builder ended with this on Cygwin. A Linux VM on the same physical computer doesn't have trouble sending to build@. I do have a VPN up which is not always o

Re: Need help debugging sp16.exe

On Mon, Oct 12, 2020 at 11:19 AM Joel Sherrill wrote: > > > > On Mon, Oct 12, 2020 at 10:47 AM Richi Dubey wrote: >>> >>> There are existing checks scattered throughout the source. Do any need to >>> be in your scheduler? >> >> I don't understand. If there are already checks scattered through, w

Re: [PATCH v2] rtems: Generate

On Sun, Oct 11, 2020 at 4:31 PM Chris Johns wrote: > > On 12/10/20 1:16 am, Sebastian Huber wrote: > > On 08/10/2020 08:18, Sebastian Huber wrote: > > > >> On 07/10/2020 21:12, Gedare Bloom wrote: > >> > >>> On Wed, Oct 7, 2020 at 11:40 AM Sebastian Huber > >>> wrote: > On 07/10/2020 17:26,

RE: aarch64/a53_ilp32_qemu: implicit declaration of function 'truncl'

On Sat, Oct 10, 2020 at 8:13 AM Sebastian Huber mailto:sebastian.hu...@embedded-brains.de>> wrote: On 10/10/2020 15:11, Sebastian Huber wrote: > Hello Kinsey, > > the new aarch64/a53_ilp32_qemu produces a lot of warnings like this: > > ../../../testsuites/psxtests/psxhdrs/math/truncl.c:45:12: wa

Re: Build fail on debian - Toolset build error

On Mon, Oct 12, 2020 at 11:38 PM Chris Johns wrote: > On 13/10/20 1:06 am, Karel Gardas wrote: > > On 10/12/20 3:50 PM, Anders Montonen wrote: > >> Hi, > >> > >>> On 12 Oct 2020, at 15:30, Karel Gardas >>> > wrote: > >>> > >>> > >>> Sure, but you have to install h

[PATCH 5/5] shell/main_edit.c: Fix string truncation warning

From: Frank Kühndel Using strlcpy() instead of strncpy(): 1) Prevents the compiler warnings 2) Ensures, the string is NUL terminated. 3) Avoids that strncpy() unnecessary fills the unused part of the buffer with 0 bytes. (Note that realpath() also returns NULL if the file does not exist - th

[PATCH 3/5] shell/shell.c: Fix illegal string copy

From: Frank Kühndel This is an illegal use of strcpy() because one is not allowed to use this function with overlapping source and destination buffers; whereas memmove() is explicitly designed to handle such cases. The copiler warning was: ../../../cpukit/libmisc/shell/shell.c:626:13: warning:

[PATCH 4/5] shell/main_edit.c: Fix use of wrong constant

From: Frank Kühndel realpath() requires a buffer of size PATH_MAX and not of size FILENAME_MAX according to 'man realpath (3)'. --- cpukit/libmisc/shell/main_edit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_

[PATCH 1/5] fsdosfsname01: Fix string truncation warning

From: Frank Kühndel This patch fixes a compiler warning: ../../../testsuites/fstests/fsdosfsname01/init.c:430:19: warning: '%s' directive output may be truncated writing up to 6424 bytes into a region of size 257 [-Wformat-truncation=] The buffer 'dirname' is exactly large enough so that no tru

[PATCH 2/5] shell/shell.c: Fix an implicit type cast

From: Frank Kühndel With some compiler warnings enabled, the implicit cast may trigger a compiler warning. The explicit cast avoids this. --- cpukit/libmisc/shell/shell.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/sh

[PATCH 0/5] Fix several warnings and minor issues

From: Frank Kühndel This set of small patches fixes a few minor issues such as compiler warnings, utilization of a wrong constant or bad uses of string copy. Frank Kühndel (5): fsdosfsname01: Fix string truncation warning shell/shell.c: Fix an implicit type cast shell/shell.c: Fix illegal

Re: Remove implementation-specific inline functions with exactly one caller?

On Tue, Oct 13, 2020 at 6:41 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > we have a couple of implementation-specific inline functions defined in > header files which have exactly one caller. I think we should remove > these functions in general, to reduce the lines

[PATCH] Remove *_Is_null() inline functions

Simply compare the values against NULL. --- cpukit/include/rtems/chain.h| 2 +- cpukit/include/rtems/rtems/asrimpl.h| 13 - cpukit/include/rtems/score/chainimpl.h | 17 - cpukit/include/rtems/score/objectmp.h | 15 --- cpukit/include/rtem

Remove implementation-specific inline functions with exactly one caller?

Hello, we have a couple of implementation-specific inline functions defined in header files which have exactly one caller. I think we should remove these functions in general, to reduce the lines of code, making code review easier, and reduce the number of functions which need documentation.

Re: libbsd need --enable-posix any more?

On 13/10/2020 10:06, Chris Johns wrote: LibBSD checks for --enable-posix. Is this check needed with rtems.git master? I haven't tried it out. It would be good to get rid of this requirement. ___ devel mailing list devel@rtems.org http://lists.rtems.or

libbsd need --enable-posix any more?

Hi, LibBSD checks for --enable-posix. Is this check needed with rtems.git master? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel