On Thu, Feb 11, 2021, 3:00 PM Chris Johns wrote:
> On 12/2/21 7:27 am, Ryan Long wrote:
> > Fixes CID #1468682 where target is dereferenced before it has been
> > checked as to whether it is null or not in the
> > rtems_debugger_target_swbreak_control function.
> > ---
> > cpukit/libdebugger/rte
On Thu, Feb 11, 2021 at 3:12 PM Gedare Bloom wrote:
> On Thu, Feb 11, 2021 at 1:28 PM Ryan Long
> wrote:
> >
> > These macros are to be used to check the status from calls that are
> flagged by
> > Coverity as 'Unchecked return value'.
> > ---
> > cpukit/include/rtems/score/assert.h | 30 ++
thing and I stated
> my
> preference in the other post.
>
No. I missed that you wanted the variable at the top of scope. I agree that
tighter scoping is more a C++ thing than a C thing. I was looking for
something
more complicated.
>
> I use this feature judicially in C++ where I
then shared?
>
If Kinsey or Jan confirms, then yes it should. Kinsey has had a number
of drivers work after addressing 64-bit clean issues.
--joel
>
> Chris
> ___
> devel mailing list
&g
On Fri, Feb 12, 2021 at 7:38 PM wrote:
> From: Chris Johns
>
> - Add support to the BSP to enable irq-generic management
>
> - Update the powerpc shared irq code to support irq-generic. This
> is an option in option for existing powerpc bsps. This change
>
Probably just an option. :)
I'm coo
ry&col=status&col=owner&col=type&col=priority&col=milestone&order=priority
Looking at Coverity is a quick way to find a small task. Some tickets
geared to adding a test aren't bad.
--joel
>
> Thanks
> Sanskar
>
>
> On Fri, Feb 12, 2021, 3:01 PM Hesham
On Sat, Feb 13, 2021, 4:16 AM Hesham Almatary
wrote:
> On Sat, 13 Feb 2021 at 10:59, Eshan Dhawan
> wrote:
> >
> >
> > On 13-Feb-2021, at 1:53 PM, Sanskar Khandelwal
> wrote:
> >
> >
> >
> >
> > On Sat, Feb 13, 2021 at 9:30 AM Joel She
at
would give a procedure more like a cross to RTEMS. Maybe they have
instructions and from there it should be straightforward plodding.
A bit of research and perhaps email to their community to ask some
questions would help size up the cross build situation.
--joel
___
af build but it didn't change the resulting
executables.
Any pointers would be appreciated.
Thanks.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hi
Looks like most of the targets failed to build on CentOS over the weekend
and ended with this:
/home/joel/rtems-
cron-6/tools/6/powerpc-rtems6/sys-include
configure: error: in `/home/joel/rtems-cron-6/rtems-source-builder/rtems/
build/powerpc-rtems6-gcc-eb15f76-newlib-d4a756f-x86_64-
linux
Should this have a ticket and be applied to 5 also? There are other 64 bit
architectures but they don't get tested as often and thoroughly.
On Mon, Feb 15, 2021, 9:12 AM Kinsey Moore wrote:
> From: ryan long
>
> The ts-validation-0 test currently fails on 64bit BSPs due to a
> limitation of the
Christian submitted a series of patches to eliminate unicode. I'd prefer if
we avoided it
On Mon, Feb 15, 2021, 8:20 AM Peter Dufault wrote:
> An international project should allow UTF in source code. You might need
> to hunt what setting you need (for gnome-terminal "export LANG=en_US.UTF-8"
>
think this will catch all stupid cases of
passing NULL but may be sufficient to catch some. I have no idea if this
will make Coverity happy or not.
I think aiming for the last two since they seem reasonable and
straightforward.
Other ideas?
--joel
___
Any idea why psim fails on buildbot but not the other BSPs run through
buildbot?
Did Amar miss updating the powerpc tools?
-- Forwarded message -
From:
Date: Wed, Feb 17, 2021 at 2:02 PM
Subject: Buildbot failure in RTEMS on powerpc/psim FreeBSD 10.1-STABLE GCC
7.3.0 POSIX
To:
On Wed, Feb 17, 2021, 2:56 PM Chris Johns wrote:
> On 18/2/21 7:18 am, Joel Sherrill wrote:
> > Any idea why psim fails on buildbot but not the other BSPs run through
> buildbot?
> >
> > Did Amar miss updating the powerpc tools?
>
> Autoconf vs waf? Buildbot is s
On Wed, Feb 17, 2021 at 3:36 PM Gedare Bloom wrote:
> On Wed, Feb 17, 2021 at 2:12 PM Joel Sherrill wrote:
> >
> >
> >
> > On Wed, Feb 17, 2021, 2:56 PM Chris Johns wrote:
> >>
> >> On 18/2/21 7:18 am, Joel Sherrill wrote:
> >> > Any i
c includes
mkdir("/dev") and a fatal error if it cannot create it.
Doesn't this mean that every call to mkdir("/dev") in a BSP or device
driver is redundant? They should be removed since the base FS contents are
always in place before any device dri
On Thu, Feb 18, 2021 at 11:06 AM Gedare Bloom wrote:
> On Thu, Feb 18, 2021 at 8:56 AM Joel Sherrill wrote:
> >
> > Hi
> >
> > There are a lot of Coverity issues related to device drivers which call
> mkdir("/dev") and ignore the return value. My first t
On Thu, Feb 18, 2021 at 11:21 AM Gedare Bloom wrote:
> On Wed, Feb 17, 2021 at 12:31 PM Sebastian Huber
> wrote:
> >
> > The api pointer is never NULL.
> >
> > Update #4244.
> > ---
> > cpukit/posix/src/psignalunblockthread.c | 6 --
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/c
On Thu, Feb 18, 2021 at 11:32 AM Gedare Bloom wrote:
> On Wed, Feb 17, 2021 at 12:30 PM Sebastian Huber
> wrote:
> >
> > Ensure that no invalid modes are set during ASR processing.
> >
> > Update #4244.
> > ---
> > cpukit/rtems/src/signalcatch.c | 27 +++
> > 1 file chan
On Thu, Feb 18, 2021 at 11:52 AM Gedare Bloom wrote:
> On Thu, Feb 18, 2021 at 10:20 AM Joel Sherrill wrote:
> >
> >
> >
> > On Thu, Feb 18, 2021 at 11:06 AM Gedare Bloom wrote:
> >>
> >> On Thu, Feb 18, 2021 at 8:56 AM Joel Sherrill wrote:
>
On Thu, Feb 18, 2021 at 2:08 PM Gedare Bloom wrote:
> On Thu, Feb 18, 2021 at 12:52 PM Joel Sherrill wrote:
> >
> >
> >
> > On Thu, Feb 18, 2021 at 11:52 AM Gedare Bloom wrote:
> >>
> >> On Thu, Feb 18, 2021 at 10:20 AM Joel Sherrill wrote:
> &
On Thu, Feb 18, 2021 at 3:28 PM Gedare Bloom wrote:
> On Thu, Feb 18, 2021 at 2:18 PM Joel Sherrill wrote:
> >
> >
> >
> > On Thu, Feb 18, 2021 at 2:08 PM Gedare Bloom wrote:
> >>
> >> On Thu, Feb 18, 2021 at 12:52 PM Joel Sherrill wrote:
> >
On Fri, Feb 19, 2021, 10:31 AM Gedare Bloom wrote:
> On Thu, Feb 18, 2021 at 11:56 PM Sebastian Huber
> wrote:
> >
> > On 18/02/2021 20:25, Joel Sherrill wrote:
> >
> > > > - /*
> > > > - * api may be NULL in case of a thread close
problem
that
started this thread?
grlib calls mkdir(/dev/leonXXX) in multiple places and does not check
the return code. This is one.
https://git.rtems.org/rtems/tree/bsps/shared/grlib/pci/gr_rasta_io.c#n577
We have existing APIs and faults, I was just asking which one to use
in thes
't this just be a debug _Assert and value not check
deliberately?
Isn't an assert something that should not happen in a properly designed
BSP. In
this case, it would be the sysinit magic that would be utterly broken.
--joel
>
> On Fri, Feb 19, 2021, 11:03 AM Joel Sherrill wrot
On Fri, Feb 19, 2021, 5:32 PM Chris Johns wrote:
> On 20/2/21 7:56 am, Joel Sherrill wrote:
> > On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom > <mailto:ged...@rtems.org>> wrote:
> >
> > I think the suggestion is to provide a catch-all rather than try to
&
k priority is another set of choices. :)
--joel
> Heinz
>
>
> > On 23. Feb 2021, at 09:17, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
> >
> > On 23/02/2021 08:36, Heinz Junkes wrote:
> >
> >> I would have a similar questio
.
I started this discussion wanting a fatal error and now I am happy just
adding _Assert_Unused_variable_equals(). If the directory doesn't end up
getting created, the mknod on the device will fail a few lines down so
there will be a failure.
--joel
> Daniel
>
>On 2021-
Any other options? Opinions.
--joel
CID 1047324: Unchecked return value in fdt_add_subnode_namelen().
Closes #4256
---
cpukit/dtc/libfdt/fdt_rw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/dtc/libfdt/fdt_rw.c b/cpukit/dtc/libfdt/fdt_
On Tue, Feb 23, 2021 at 9:50 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:
> Hello Joel,
>
> Am 23.02.21 um 16:23 schrieb Joel Sherrill:
> > Hi
> >
> > Ryan has wandered into the land of third party code and Coverity issues.
> > It i
application to
include all pthread attribute set methods.
I don't have a good solution in mind. :(
> Heinz
>
> > On 23. Feb 2021, at 15:17, Joel Sherrill wrote:
> >
> >
> >
> > On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes
> wrote:
> > what I
On Tue, Feb 23, 2021, 2:36 PM Chris Johns wrote:
> On 24/2/21 3:29 am, Christian MAUDERER wrote:
> > Yes, I know. Upstream loops can be quite time consuming. I'm waiting
> since about
> > half a year that a FreeBSD patch for the i.MX6ULL SDHCI gets reviewed
> (after
> > someone here suggested it
I'm missing an operational view of this even from all the pieces and parts.
It looks like there's a hash for some characteristics of the RTEMS build
and another related to the bsp. But I don't see any documentation about
what the intent of this from a system viewpoint and how a systems
integrator w
On Wed, Feb 24, 2021 at 12:43 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 24/02/2021 19:37, Joel Sherrill wrote:
>
> > I'm missing an operational view of this even from all the pieces and
> > parts. It looks like there's a hash for som
Hi
Just passing along that the need to switch the BSP builder to waf is
becoming more obvious in the BSP Builder results
https://lists.rtems.org/pipermail/build/2021-February/026054.html
467 of 1615 configurations now fail to build.
-joel
___
devel
On Thu, Feb 25, 2021 at 11:15 AM junkes wrote:
> Hallo Joel,
> unfortunately, even with waf, it still does not work as it should.
>
Building and not working is slightly better but still bad. :(
The bsp-builder doesn't run any tests. I do run automated test runs on a
number of
Some odd questions that are mostly about making this a self-contained
entity with no loose ends.
+ Can the network demos be merged also?
+ rtems-docs has the Network Users Guide which is legacy only. As a
minimum, it needs to be renamed to have Legacy in the title. Better would
be to convert it t
On Fri, Feb 26, 2021, 11:40 AM Vijay Kumar Banerjee wrote:
> Hi all,
>
> Thanks for reviewing
>
> On Fri, Feb 26, 2021 at 10:13 AM Joel Sherrill wrote:
> >
> > Some odd questions that are mostly about making this a self-contained
> entity with no loose ends.
>
On Fri, Feb 26, 2021, 11:49 AM Chris Johns wrote:
> On 27/2/21 4:40 am, Vijay Kumar Banerjee wrote:
> > Hi all,
> >
> > Thanks for reviewing
> >
> > On Fri, Feb 26, 2021 at 10:13 AM Joel Sherrill wrote:
> >>
> >> Some odd questions that are
c/getgrent.c:109:
> > undefined reference to `_Assert_Unused_variable_equals'
> > collect2: error: ld returned 1 exit status
> > ```
> > Looks like assert.h isn't included from getgrent.c . I have attached a
> > patch to add the header files and checked that
Looks good.
On Fri, Feb 26, 2021, 5:59 PM wrote:
> From: Chris Johns
>
> - It seems the compiler how defaults to -fcommon and this means
> some uninitialised data is ignored.
>
> Closes #4266
> ---
> bsps/powerpc/motorola_powerpc/bootloader/ppcboot.lds | 8 +++-
> 1 file changed, 7 inser
nk so. please post to
both devel@ and users@ that your repo needs testing and that the
legacy stack is soon to be removed from the main rtems.git.
And make it VERY clear that anyone who plans to test, please
speak up. We can't demand they do it immediately but it would
be help
On Tue, Mar 2, 2021 at 9:46 AM Gedare Bloom wrote:
> On Mon, Mar 1, 2021 at 1:01 PM Alex White
> wrote:
> >
> > The tester configurations had not been updated to match the paths and
> > conventions used by the new build system. These have been updated,
> > and a few more libraries have been enab
I think almost all of the patch process and git instructions
have
been added to the docs but are still in the Wiki. There may be a section
that
remains to be converted but it needs review, missing content added to the
docs,
and then deletion. De
>
> HEAP_ERROR_FREE_PATTERN
> There is an unexpected value in the free pattern of a free heap block.
>
> I will try to find out more about this error.
>
Based on the name and you building with debug on, I would guess that
something has written past the end of its allocated ar
On Tue, Mar 2, 2021 at 10:23 AM Gedare Bloom wrote:
> On Mon, Mar 1, 2021 at 1:02 PM Alex White
> wrote:
> >
> > Some NOP instructions were not being marked as executed because they
> > are located at the end of uncovered ranges. This has been fixed.
> > ---
> > tester/covoar/CoverageMapBase.cc
k or normal root
> directory?
> >
> This is done in a different repo: https://git.rtems.org/rtems-docs/
> @Joel Sherrill Do you know what is status on this project?
>
The script to do the conversion was finished by the student. I experimented
with including the generated output in
On Tue, Mar 2, 2021 at 1:50 PM Gedare Bloom wrote:
> On Tue, Mar 2, 2021 at 12:37 PM Joel Sherrill wrote:
> >
> >
> >
> > On Tue, Mar 2, 2021 at 12:47 PM Gedare Bloom wrote:
> >>
> >> On Tue, Mar 2, 2021 at 11:25 AM Dev Agrawal
> wrote:
> &g
On Tue, Mar 2, 2021 at 2:59 PM Vijay Kumar Banerjee wrote:
> On Tue, Mar 2, 2021 at 1:46 PM Joel Sherrill wrote:
> >
> >
> >
> > On Tue, Mar 2, 2021 at 1:50 PM Gedare Bloom wrote:
> >>
> >> On Tue, Mar 2, 2021 at 12:37 PM Joel Sherrill wrote:
>
On Tue, Mar 2, 2021 at 4:48 PM Chris Johns wrote:
> On 3/3/21 3:54 am, Gedare Bloom wrote:
> > On Tue, Mar 2, 2021 at 8:52 AM Joel Sherrill wrote:
> >> On Tue, Mar 2, 2021 at 9:46 AM Gedare Bloom wrote:
> >>>
> >>> On Mon, Mar 1, 2021 at 1:01 PM Ale
the
> covoar
> changes?
>
That's what Gedare asked for when he suggested splitting the set into
areas.
Alex can you separate out the RLD?
If Chris was ok with them all, just repost them as a self-contained set and
he can ack the cover-letter for the RLD set.
The set needs to
rs to the legacy stack.
At this point, the "newer BSD" is quite old and the BSD version in
the legacy stack is ancient. Lesson is using old, new, future, next
generation, etc with technology is inevitable to be wrong eventually.
In file included from
> ../../bsps/powerpc/beatnik/net/por
re beyond the
first 32-bits.
Sometimes it is easy to binary search for an issue like this
on a simulator. But with a watchpoint, you should be able to
determine the precise word which is corrupted in the fence
and break on that write.
--joel
>
> > (gdb) c
> > Continuing.
&
On Wed, Mar 3, 2021 at 11:14 AM Vijay Kumar Banerjee
wrote:
> Hello Heinz, Joel,
>
>
> On Wed, Mar 3, 2021 at 7:03 AM Joel Sherrill wrote:
> >
> >
> >
> > On Wed, Mar 3, 2021 at 3:39 AM junkes wrote:
> >>
> >> Dear Vijay,
> >&g
f won't have this at all. It will always have no
networking and you have to add a stack.
This may be something that needs addressing. Not sure.
--joel
> Danke Heinz
> .
>
> > On 3. Mar 2021, at 21:03, Vijay Kumar Banerjee wrote:
> >
> > On Wed, Mar 3, 2021 at 1
This patch has been merged into newlib as of Feb 10 but the RSB for the
newlib for rtems6 tools is from Jan 22.
Any issues with updating newlib to pick this up so I can begin to merge
Eshan's ftw tests?
commit bebb25961c1ed29d217b1a40fc69c77ebdc18bcd
Author: Corinna Vinschen
Date: Sun Feb 10 1
Does anyone object to this? There were no comments and I will shortly merge
this if no one speaks up
On Mon, Feb 8, 2021 at 10:26 AM Eshan Dhawan
wrote:
> From: Eshan dhawan
>
> Closes #3373
>
> Signed-off-by: Eshan Dhawan
> ---
> cpukit/Makefile.am| 1 +
> cpuki
r.
>
> The message size is already size_t. The problem is the
> maximum_pending_messages. I think that limiting the maximum for the
> pending messages to 65535 would be a bit too restrictive.
>
I know of one satellite that used a message queue to enqueue all data to
be d
be there. This SHOULD be
equivalent to prior split.
But I suppose this now means you could have the BSP, legacy stack
and libbsd installed in different places and setup include and library
paths to let the application build system decide which stack to us.
---joel
>
> Heinz
>
> On 2
need to be in the legacy stack
package. But until the port of the FreeBSD NFSv4 client is available
in libbsd, the existing NFSv2 client has to be used for both stacks.
I suppose this may end up being the one piece of lingering clean up.
--joel
> Heinz
>
>
> > On 4. Mar 2021, a
Thanks Sebastian. I built this newlib hash yesterday for all targets on
Centos and was about to test Eshan's ftw test patches.
I'm hoping an our of date toolset causes test failures and not build
failures.
Are we at a point where a forced tool upgrade might be acceptable?
--joel
On
e_error=2125180) at
> /home/richi/quick-start/LatestStrong/src/rtems/c/src/../../cpukit/score/src/interr.c:38
> 38 _User_extensions_Fatal( the_source, the_error );
>
>
>
> On Wed, Mar 3, 2021 at 10:20 PM Gedare Bloom wrote:
>
>> On Wed, Mar 3, 2021 at 9:49 AM Gedare Bloom wrote:
>
On Fri, Mar 5, 2021, 9:08 AM Gedare Bloom wrote:
> On Thu, Mar 4, 2021 at 12:50 PM Ryan Long
> wrote:
> >
> > CID 1399768: Unsigned compared against 0 in satcan_ioctl().
> >
> > Closes #4294
> > ---
> > bsps/shared/grlib/can/satcan.c | 16
> > 1 file changed, 4 insertions(+), 1
o not object but this is an impactful thing to do and it would
be my preference to get concurrence from multiple core
developers.
--joel
>
>
>
> Best regards,
> Vijay
>
>
> On Mon, Mar 1, 2021, 14:48 Vijay Kumar Banerjee wrote:
>
>> On Mon, Mar 1, 2021 at 1:24 P
On Fri, Mar 5, 2021 at 11:42 AM Jan Sommer wrote:
> v3:
> - Make sure the baud registers are not modified for baud rate B0
>
B0 is an odd bird. It indicates hang up. From
https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/tcsetattr.html
:
If the output baud rate stored in th
On Fri, Mar 5, 2021, 12:25 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> On 05/03/2021 16:27, Gedare Bloom wrote:
>
> > Should we add a macro for this, e.g., "RTEMS_CASE_NO_BREAK" so that we
> > can update them in future if needed for other tools?
> I would just pick a name whi
Unfortunately newlib needs to bump again to catch the minor fix
-- Forwarded message -
From: Eshan Dhawan via Newlib
Date: Fri, Mar 5, 2021, 1:27 PM
Subject: Makefile.in not regenerated for libc/posix
To: Newlib
Hello,
Makefile.in wasn’t regenerated for libc/posix
For the commi
add some configurations for the new build system
> before I can push them to RTEMS/master.
>
Thanks for submitting all these. Is this going to clean your queue?
--joel
> Thanks,
> /Daniel
>
>
> Kind Regards,
> Daniel
>
> On 2020-09-18 10:03, Sebastian Huber wrote:
On Fri, Mar 5, 2021, 1:07 PM Gedare Bloom wrote:
> On Fri, Mar 5, 2021 at 11:42 AM Vijay Kumar Banerjee
> wrote:
> >
> > ---
> > netlegacy.py | 27 +--
> > testsuites/telnetd01/wscript | 2 +-
> > 2 files changed, 22 insertions(+), 7 deletions(-)
> >
> >
LED
> > Build Set: Time 0:00:00.046141
> > Build FAILED
> >
> > ```
> >
> > Commenting these checks from rtems-bsp.cfg gets it building.
>
> Unfortunately the checks are needed and this is not the answer.
>
> I wonder how Jennifer has been building libb
se type of "temporary"
hacks.
Thanks
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
he
> toolchain bump, that should give enough time for anyone who wants to
> complain to do so, and to notice that they should update their
> toolchai
>
Thanks for the quick reply.
This was my email asking. :I hate to cause people a bit of pain but building
up cruft is also bad.
--joel
&
Should I file a ticket for someone to do the assessment of what was added?
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee wrote:
> Hello,
>
> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee
> wrote:
> >
> > On Fri, Mar 5, 2021 at 9:37 AM Joel Sherrill wrote:
> > >
> > >
> > >
> > > On Fri, Mar 5, 202
On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee
wrote:
> On Tue, Mar 9, 2021 at 9:56 PM Chris Johns wrote:
> >
> > On 10/3/21 3:51 pm, Gedare Bloom wrote:
> > > On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill wrote:
> > >> On Tue, Mar 9, 2021, 3
Hi
I see qemu hanging for days testing zynq. This is on the Xeon Centos
computer I use for batch and automated testing.
This is ps but top shows six qemu processes having around 2231:52 in CPU
time used and using 100% CPU. Luckily this machine has more cores than this.
Any ideas?
[joel@devel
On Tue, Mar 9, 2021 at 3:07 PM Gedare Bloom wrote:
> On Tue, Mar 9, 2021 at 1:51 PM Joel Sherrill wrote:
> >
> > Hi
> >
> > Looks like a set of new APIs are coming to POSIX. See
> >
> > https://www.opengroup.org/austin/docs/austin_1110.pdf
> >
>
On Wed, Mar 10, 2021 at 11:48 AM Chris Johns wrote:
>
>
> On 11/3/21 1:11 am, Joel Sherrill wrote:
> > On Tue, Mar 9, 2021 at 11:00 PM Vijay Kumar Banerjee > <mailto:vi...@rtems.org>> wrote:
> >
> > On Tue, Mar 9, 2021 at 9:56 PM Chris Johns
On Wed, Mar 10, 2021 at 11:42 AM Chris Johns wrote:
> On 11/3/21 1:22 am, Joel Sherrill wrote:
> > I see qemu hanging for days testing zynq. This is on the Xeon Centos
> computer I
> > use for batch and automated testing.
> >
> > This is ps but top shows six qemu p
ewlib is used by both Cygwin and Newlib.
Thanks.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re-adding devel@ to keep things recorded.
On Thu, Mar 11, 2021 at 1:23 PM Alireza Banejad
wrote:
> Hello Joel,
> thank you for responding,
> so basically I installed the msys2 i686 and downloaded the packages and
> finally downloaded themingw-w64-i686-toolchain, after exporting
Without looking, I would assume this was introduced by Daniel's recent
patches.
-- Forwarded message -
From:
Date: Fri, Mar 12, 2021, 12:55 AM
Subject: New Defects reported by Coverity Scan for RTEMS
To:
Hi,
Please find the latest report on new defect(s) introduced to RTEMS fo
y
run automatically about midnight Central time every night if there were any
changes to the RSB or RTEMS repos. Then it sends an email to build@ if
any new issues turned up. Definitely progress has been made here.
--joel
On Fri, Mar 12, 2021 at 7:22 AM Daniel Hellstrom wrote:
> yes, it must ha
?
configure:3804:
/home/joel/rtems-cron-6/rtems-source-builder/rtems/build/m68k-rtems6-gcc-6051af8-newlib-d10d0d9-x86_64-linux-gnu-1/build/./gcc/xgcc
-B/home/joel/rtems-cron-6/rtems-source-builder/rtems/build/m68k-rtems6-gcc-6051af8-newlib-d10d0d9-x86_64-linux-gnu-1/build/./gcc/
-nostdinc
-B/home/joel
hese added. Any advice for how we can use
these in the project. Compare architectures? RTEMS versions?
--joel
On Sat, Mar 13, 2021 at 1:50 AM Hesham Almatary <
hesham.almat...@cl.cam.ac.uk> wrote:
> CoreMark's primary goals are simplicity and providing a method for
> test
On Fri, Mar 12, 2021 at 5:47 PM Chris Johns wrote:
> These are design question and not review issues
>
> On 12/3/21 5:33 am, Alex White wrote:
> > + // Create data based on target.
> > + TargetInfo = Target::TargetFactory( buildTarget );
>
> Any pointers in this object given there is a cop
On Sun, Mar 14, 2021, 9:27 PM Chris Johns wrote:
>
>
> On 13/3/21 2:18 am, Ryan Long wrote:
> > CID 1439298: Resource leak in rtems_fdisk_initialize().
> >
> > Closes #4299
> > ---
> > cpukit/libblock/src/flashdisk.c | 42
> ++---
> > 1 file changed, 31 insert
com/RTEMS/rtems-examples/blob/983926a7e519be85f630c620430e7e1ac3e0f4ea/README.Makefile#L32
There are projects that use it. Although it is old and it would be nice to
go to something else, that something else isn't there. It's there.foenthe
foreseeable future.
--joel
>
>
>
> On Sun, 14 Mar 20
ects here. My question is not conflict on
project choice, it is whether either is an appropriate GSoC project. With
the shorter time frame, I think the scope of the project is in the right
ballpark.
Is there enough coding? I don't know.
--joel
>
> On Mon, 15 Mar 2021 at 09:45, Ida Delp
If this matches the state of the got master, then ok.
On Mon, Mar 15, 2021, 7:55 AM wrote:
> Could someone please have a look at this patch?
>
> > -Original Message-
> > From: Sommer, Jan
> > Sent: Friday, March 5, 2021 7:04 PM
> > To: devel@rtems.org
> > Cc: Sommer, Jan
> > Subject: [P
anges and some don't. Ryan and
I looked at main_cp.c and it had at least 40 revisions since the version
we have. The same Coverity issue appeared to be present but the variable
names were changed and much clearer.
Chris imported this code initially. I'll
On Mon, Mar 15, 2021, 3:21 PM Gedare Bloom wrote:
> On Fri, Mar 12, 2021 at 7:55 AM Ryan Long wrote:
> >
> > CID 26033: Dereference after null check in _Objects_Extend_information().
> >
> > Closes #4326
> > ---
> > cpukit/score/src/objectextendinformation.c | 11 +++
> > 1 file changed
On Mon, Mar 15, 2021, 3:10 PM Gedare Bloom wrote:
> On Fri, Mar 12, 2021 at 8:18 AM Ryan Long wrote:
> >
> > CID 1439297: Resource leak in rtems_nvdisk_initialize().
> >
> > Closes #4298
> > ---
> > cpukit/libblock/src/nvdisk.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
>
4
> entries
> but we had 1024 in the code previously and it was fine so I am also OK if
> it
> left that way.
>
This is a different case than many of the others, it is reading a block of
fixed size
binary entries from the Qemu trace log. It is just avoiding reading the
32-byt
On Mon, Mar 15, 2021 at 6:01 PM Chris Johns wrote:
>
>
> On 16/3/21 6:55 am, Joel Sherrill wrote:
> >
> >
> > On Mon, Mar 15, 2021 at 2:46 PM Gedare Bloom > <mailto:ged...@rtems.org>> wrote:
> >
> > On Sun, Mar 14, 2021 at 8:27 PM
On Mon, Mar 15, 2021, 6:10 PM Chris Johns wrote:
> On 15/3/21 2:21 pm, Joel Sherrill wrote:
> > On Sun, Mar 14, 2021, 9:27 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
> > On 13/3/21 2:18 am, Ryan Long wrote:
> > > CID 1439298: Res
On Mon, Mar 15, 2021, 8:00 PM Chris Johns wrote:
> On 16/3/21 11:49 am, Joel Sherrill wrote:
> > On Mon, Mar 15, 2021, 6:10 PM Chris Johns > <mailto:chr...@rtems.org>> wrote:
> >
> > On 15/3/21 2:21 pm, Joel Sherrill wrote:
> > >
g with the rtems-tester on CentOS for a handful
of tests. That last one I need to look into.
--joel
On Tue, Mar 16, 2021 at 6:46 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello Joel,
>
> I updated the tools today. Maybe the error disappeared. It builds fine
&
On Tue, Mar 16, 2021 at 9:15 AM Ryan Long wrote:
> I found this error yesterday, when doing more testing based on Chris's
> feedback. I've taken out the _Assert_Unused_variable_equals() in pwdgrp.c
> and replaced it with just a (void). The test passed afterwards, but Joel
>
1001 - 1100 of 6233 matches
Mail list logo
