Re: [PATCH rtems-libbsd 1/2] racoon/session: Honor file descriptor maximum

Hello Chris, Am 02.03.21 um 01:03 schrieb Chris Johns: On 1/3/21 7:24 pm, Christian MAUDERER wrote: Hello Chris, thanks for the review. Am 26.02.21 um 19:04 schrieb Chris Johns: On 26/2/21 2:01 am, Christian Mauderer wrote: Dynamically allocate a big enough file descriptor set for select().

Need help in deciding GSoC project also want to know project Scope

Hi everyone,  I have decided following projects to work on this Summer. Please let me know about the scope of the project, whether it's feasible to work during GSoC.  1. https://devel.rtems.org/wiki/Developer/Projects/Open/UsingClang:    2. Ticket 4182: https://devel.rtems.org/ticket/4182 Rea

[PATCH] rtems: Simplify _Signal_Action_handler()

Use the invariant that a ASR is only processed if ASR processing is enabled. --- cpukit/rtems/src/signalsend.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/cpukit/rtems/src/signalsend.c b/cpukit/rtems/src/signalsend.c index 8c4ce10788..72407e2b01 100644 --- a/cpu

Re: Need help in deciding GSoC project also want to know project Scope

Hi Sebastian, Thanks for your suggestion :)  Regards, Prateek Pardeshi  On Tue, 02 Mar 2021 12:47:41 +0530 Sebastian Huber wrote Hello Prateek Pardeshi, an interesting LLVM related project could be trying out MULL with RTEMS. https://github.com/mull-project/mull I had o

[PATCH] rtems: Simplify rtems_signal_catch()

In uniprocessor configurations, we can simplify rtems_signal_catch(). Add a validation tests for the SMP special case. --- cpukit/rtems/src/signalcatch.c | 19 +- testsuites/validation/tc-signal-catch.c | 648 2 files changed, 566 insertions(+), 101 deletions(-)

Re: [PATCH v1 1/2] score: Enforce stack_end alignment

Hello Kinsey, I think the root cause is that this is not necessarily stack aligned: On 01/03/2021 23:59, Kinsey Moore wrote: thread_config->stack_area = _Stack_Allocate( size ); Also this (easy to fix): /**  * @ingroup RTEMSAPIClassicTasks  *  * @brief This constant defines the recommended a

Question regarding an open project and documentation enhancement

1. Hello everyone, I went through open ticket "Code Formatting and Style Check for RTEMS score" (https://devel.rtems.org/ticket/3860) as a possible GSOC project and discussion thread on it https://lists.rtems.org/pipermail/devel/2020-February/057246.html, https://lists.rtems.org/pipermail/devel/20

Re: Question regarding an open project and documentation enhancement

On 02/03/2021 16:08, Ayushman Mishra wrote: 1. Hello everyone, I went through open ticket "Code Formatting and Style Check for RTEMS score" (https://devel.rtems.org/ticket/3860) as a possible GSOC project and discussion thread on it https://lists.rtems.org/pipermail/devel/2020-February/057246.h

Re: [PATCH 01/22] tester: Update to support new build system

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 enabled in symbol-sets.ini. > --- > tester/rtems/testing/bsps/griscv

Re: [PATCH 00/22] tester: Update covoar for new build system

On Mon, Mar 1, 2021 at 1:01 PM Alex White wrote: > > This patch set updates the covoar tool to allow it to work with the > outputs of the current build system. It includes various fixes and > improvements needed to successfully produce coverage reports for the > following BSP configurations: grisc

Re: [PATCH 03/22] covoar/TargetBase: Update branchInstructions variable name

minor nit, the commit message could be clearer, like "covoar: rename branchInstructions to conditionalBranchInstructions" On Mon, Mar 1, 2021 at 1:01 PM Alex White wrote: > > The TargetBase class contains a member variable named > branchInstructions. The name omits the fact that it is only meant

Re: [PATCH 01/22] tester: Update to support new build system

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

Re: Question regarding an open project and documentation enhancement

On Tue, Mar 2, 2021 at 9:08 AM Ayushman Mishra wrote: > 1. Hello everyone, I went through open ticket "Code Formatting and > Style Check for RTEMS score" (https://devel.rtems.org/ticket/3860) as > a possible GSOC project and discussion thread on it > https://lists.rtems.org/pipermail/devel/2020-

Re: About HEAP error

On Mon, Mar 1, 2021 at 10:44 PM Richi Dubey wrote: > Oh, that makes sense. Thank you. > > I got this: > > (gdb) p *(Heap_Error_context*)(0x00206d7c) > $5 = { > heap = 0x202ba8 <_Workspace_Area>, > block = 0x206fec, > reason = HEAP_ERROR_FREE_PATTERN > } > > HEAP_ERROR_FREE_PATTERN > There i

Re: [PATCH 12/22] covoar: Fix NOP execution marking

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 | 10 +++ > tester/covoar/CoverageMapBase.h | 4 ++ > tester/

Re: [PATCH 12/22] covoar: Fix NOP execution marking

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

Re: Need help in deciding GSoC project also want to know project Scope

Hi Prateek, On Mon, Mar 1, 2021 at 10:31 PM Prateek Pardeshi wrote: > > Hi everyone, > I have decided following projects to work on this Summer. Please let me know > about the scope of the project, whether it's feasible to work during GSoC. > > > 1. https://devel.rtems.org/wiki/Developer/Project

Re: [PATCH] rtems: Simplify rtems_signal_catch()

These two simplifications look ok On Tue, Mar 2, 2021 at 6:11 AM Sebastian Huber wrote: > > In uniprocessor configurations, we can simplify rtems_signal_catch(). > Add a validation tests for the SMP special case. > --- > cpukit/rtems/src/signalcatch.c | 19 +- > testsuites/validation/t

Re: [PATCH 01/22] tester: Update to support new build system

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 Alex White wrote: >> > >> > The tester configurations had not been updated to match the paths and >> > conventions used by the new build system. The

Re: Question regarding an open project and documentation enhancement

On Tue, Mar 2, 2021 at 9:11 AM Joel Sherrill wrote: > > > > On Tue, Mar 2, 2021 at 9:08 AM Ayushman Mishra > wrote: >> >> 1. Hello everyone, I went through open ticket "Code Formatting and >> Style Check for RTEMS score" (https://devel.rtems.org/ticket/3860) as >> a possible GSOC project and di

Status for open projects for gsoc

Hello everyone, I am interested in contributing to a few topics but I don't know what is the current status and future enhancements you are looking for so if you can guide me it would be a big help. 1. # Automate Conversion of Newlib Markup to Sphinx : To

Re: Status for open projects for gsoc

On Tue, Mar 2, 2021 at 11:25 AM Dev Agrawal wrote: > > Hello everyone, > I am interested in contributing to a few topics but I don't know what is the > current status and future enhancements you are looking for so if you can > guide me it would be a big help. > > 1. # Automate Conversion of

Re: [PATCH v4 1/2] bsps/beagle: Adding QEP driver support to BeagleBoneBlack BSP

Hello James, thanks for the patches. I pushed them. Best regards Christian On 23/02/2021 09:18, James Fitzsimons wrote: --- bsps/arm/beagle/headers.am | 2 + bsps/arm/beagle/include/bsp/bbb-pwm.h | 11 - bsps/arm/beagle/include/bsp/pwmss.h | 54 +++ bsps/arm/beagle

Re: Status for open projects for gsoc

On Tue, Mar 2, 2021 at 12:47 PM Gedare Bloom wrote: > On Tue, Mar 2, 2021 at 11:25 AM Dev Agrawal > wrote: > > > > Hello everyone, > > I am interested in contributing to a few topics but I don't know what is > the current status and future enhancements you are looking for so if you > can guide m

[PATCH v2 1/3] score: Enforce stack and TLS alignment

Enforce alignment of the stack begin and end by allocating enough stack area that the desired size can be aligned to CPU_STACK_ALIGNMENT. This also ensures that the space reserved for TLS data falls on stack alignment boundaries which satisfies TLS alignment requirements. --- cpukit/rtems/src/task

[PATCH v2 3/3] bsps/aarch64: Resolve usage of SUBALIGN()

Remove usage of SUBALIGN() in aarch64 linkcmds which works around a difference in behavior on AArch64 platforms. This is no longer necessary since alignment is now enforced explicitly. Closes #4178. --- bsps/aarch64/shared/start/linkcmds.base | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions

[PATCH v2 2/3] cpukit: Explicitly enforce alignment requirements

According to commentary on GCC bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143, the alignment behavior of linker sections on which RTEMS has relied was never guaranteed to be consistent across platforms and any alignment requirements for linker sections needs to be enforced explicitly. This

Re: Status for open projects for gsoc

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: >> > >> > Hello everyone, >> > I am interested in contributing to a few topics but I don't know what is >> > the current stat

Re: [PATCH v2 2/3] cpukit: Explicitly enforce alignment requirements

On Tue, Mar 2, 2021 at 12:48 PM Kinsey Moore wrote: > > According to commentary on GCC bug > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143, the alignment > behavior of linker sections on which RTEMS has relied was never > guaranteed to be consistent across platforms and any alignment > requir

Re: Status for open projects for gsoc

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: > >> > > >> > Hello everyone, > >> > I am interested in c

Re: Status for open projects for gsoc

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 12:47 PM Gedare Bloom wrote: >> >> >> >> On Tue, Mar 2, 2021 at 11:25 AM Dev Agraw

Re: [PATCH v2 1/3] score: Enforce stack and TLS alignment

On 02/03/2021 20:47, Kinsey Moore wrote: Enforce alignment of the stack begin and end by allocating enough stack area that the desired size can be aligned to CPU_STACK_ALIGNMENT. This also ensures that the space reserved for TLS data falls on stack alignment boundaries which satisfies TLS alignm

RE: [PATCH v2 2/3] cpukit: Explicitly enforce alignment requirements

-Original Message- From: Gedare Bloom Sent: Tuesday, March 2, 2021 14:01 To: Kinsey Moore Cc: devel@rtems.org Subject: Re: [PATCH v2 2/3] cpukit: Explicitly enforce alignment requirements > On Tue, Mar 2, 2021 at 12:48 PM Kinsey Moore wrote: >> +/* >> + * The use of explicit alignment

Re: Status for open projects for gsoc

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

RE: [PATCH v2 1/3] score: Enforce stack and TLS alignment

-Original Message- From: Sebastian Huber Sent: Tuesday, March 2, 2021 15:09 To: Kinsey Moore ; devel@rtems.org Subject: Re: [PATCH v2 1/3] score: Enforce stack and TLS alignment > On 02/03/2021 20:47, Kinsey Moore wrote: >> Enforce alignment of the stack begin and end by allocating enoug

Re: [PATCH 01/22] tester: Update to support new build system

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 Alex White wrote: The tester configurations had not been updated to match the paths and convent

Re: [PATCH 02/22] tester: Add coverage variants for a few BSPs

On 2/3/21 7:01 am, Alex White wrote: > Adds coverage variants for the following BSPs: a53_qemu, pc686, > xilinx_zynq_a9_qemu, and xilinx_zynqmp. > --- > tester/rtems/testing/bsps/a53_qemu-cov.ini| 41 ++ > tester/rtems/testing/bsps/pc-qemu-cov.ini | 42 +++ >

Re: [PATCH 01/22] tester: Update to support new build system

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 Alex White > wrote: > > The tester con

Re: [PATCH 09/22] covoar: Fix DWARF reading

On 2/3/21 7:01 am, Alex White wrote: > There were a couple of issues with the way the DWARF info was being > read. The first issue was that it inefficiently included all symbols, > even symbols that were not desired. The second issue is that it did > not handle inline functions correctly. These hav

Re: [PATCH 10/22] dwarf: Fix get_source

On 2/3/21 7:01 am, Alex White wrote: > The file::get_source method was giving "unknown:-1" for valid > addresses. This has been fixed. +1 Chris > --- > rtemstoolkit/rld-dwarf.cpp | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoo

Re: [PATCH 09/22] covoar: Fix DWARF reading

On Tue, Mar 2, 2021 at 5:16 PM Chris Johns wrote: > On 2/3/21 7:01 am, Alex White wrote: > > There were a couple of issues with the way the DWARF info was being > > read. The first issue was that it inefficiently included all symbols, > > even symbols that were not desired. The second issue is th

Re: [PATCH 18/22] covoar: Add option to create named objdumps

On 2/3/21 7:01 am, Alex White wrote: > This adds a new macro USE_TEMPLFILE which allows the creation of named > objdump outputs in the /tmp directory. This allows the outputs to be > reused on subsequent runs of covoar rather than running objdump again. Is the USE_TEMPLFILE macro a debugging aid?

Re: [PATCH 09/22] covoar: Fix DWARF reading

On 3/3/21 10:32 am, Joel Sherrill wrote: > On Tue, Mar 2, 2021 at 5:16 PM Chris Johns > wrote: > > On 2/3/21 7:01 am, Alex White wrote: > > There were a couple of issues with the way the DWARF info was being > > read. The first issue was that it inefficiently

Re: [PATCH 01/22] tester: Update to support new build system

On 3/3/21 10:06 am, 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

Re: [PATCH rtems-libbsd 1/2] racoon/session: Honor file descriptor maximum

On 2/3/21 7:26 pm, Christian MAUDERER wrote: > Hello Chris, > > Am 02.03.21 um 01:03 schrieb Chris Johns: >> On 1/3/21 7:24 pm, Christian MAUDERER wrote: >>> Hello Chris, >>> >>> thanks for the review. >>> >>> Am 26.02.21 um 19:04 schrieb Chris Johns: On 26/2/21 2:01 am, Christian Mauderer wr

Re: Need help in deciding GSoC project also want to know project Scope

Hi Gedare, On Tue, 02 Mar 2021 22:19:26 +0530 Gedare Bloom wrote > Hi Prateek, > > On Mon, Mar 1, 2021 at 10:31 PM Prateek Pardeshi > wrote: > > > > Hi everyone, > > I have decided following projects to work on this Summer. Please let me > > know about the scope of th

Re: About HEAP error

Thank you for the suggestion. I will look into it. On Tue, Mar 2, 2021 at 9:43 PM Joel Sherrill wrote: > > > On Mon, Mar 1, 2021 at 10:44 PM Richi Dubey wrote: > >> Oh, that makes sense. Thank you. >> >> I got this: >> >> (gdb) p *(Heap_Error_context*)(0x00206d7c) >> $5 = { >> heap = 0x202ba8

Re: About HEAP error

On 02/03/2021 05:44, Richi Dubey wrote: (gdb) p *(Heap_Error_context*)(0x00206d7c) $5 = {   heap = 0x202ba8 <_Workspace_Area>,   block = 0x206fec,   reason = HEAP_ERROR_FREE_PATTERN } If it is always the same address, then you can set a watch point to an element which is written after the fr

Re: About HEAP error

What's the element written after the free? I set a watch at the exact block location, but it doesn't work: Hardware watchpoint 7: *0x202ba8 (gdb) watch *0x206fec Hardware watchpoint 8: *0x206fec (gdb) c Continuing. Thread 1 hit Breakpoint 6, Init (argument=2107944) at /home/richi/quick-start/Late

Re: [6-freebsd-12 PATCH 1/2] rtemsbsd/bus: Add PCI support to the nexus bus

On 19/2/21 9:02 am, Chris Johns wrote: > On 17/2/21 4:54 pm, Sebastian Huber wrote: >> On 17/02/2021 03:20, Chris Johns wrote: >>> On 16/2/21 5:49 pm, Chris Johns wrote: On 16/2/21 5:05 pm, Sebastian Huber wrote: I prefer the first option with the increased build time due to including >>