Re: [PATCH 1/5] hexdump-parse.c: Fix Resource leak (CID #26032)

On Mon, Mar 15, 2021 at 5:14 PM Chris Johns wrote: > > On 16/3/21 10:07 am, Joel Sherrill wrote: > > 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 Gedar

Re: [PATCH 4/5] flashdisk.c: Fix Resource leak (CID #1439298)

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 > > wrote: > > > > On 15/3/21 2:21 pm, Joel Sherrill wrote: > > > On Sun, Mar 14, 2021, 9:27 PM Chris Johns >

Re: code reformatting was Re: Regarding gsoc project 3860

I am extremely sorry for my behaviour and promise that this won't happen again . Actually I am pretty new to open source community ( I have contributed before but not interacted a lot with other people) and I am really grateful to you for pointing out my mistake , I will definitely make sure about

Re: [PATCH 4/5] flashdisk.c: Fix Resource leak (CID #1439298)

On 16/3/21 11:49 am, Joel Sherrill wrote: > 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 > >

Re: [PATCH 4/5] flashdisk.c: Fix Resource leak (CID #1439298)

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 > > wrote: > > On 13/3/21 2:18 am, Ryan Long wrote: > > > CID 1439298: Resource leak in rtems_fdisk_initialize(). > > > >

Re: [PATCH] covoar: Handle periods in symbols from objdump

On 16/3/21 8:26 am, Alex White wrote: > The exceptions are being used as legitimate error cases. The "what" messages > that I use here are not helpful. I think that's why it looks like they're > being used as labels. Understood and thanks. > As part of a revision of my "covoar: Fix NOP executi

Re: [PATCH v2] covoar: Handle periods in symbols from objdump

On 16/3/21 9:04 am, Alex White wrote: > Occasionally the compiler will generate symbols that look similar to > symbols defined in RTEMS code except that they contain some suffix. > This looks to be related to compiler optimizations. Such symbols were > being treated as unique. For our purposes, the

Re: [PATCH v2 0/4] coverage/reports: Improve coverage reports

OK. Nice change and thank you. Chris On 16/3/21 9:09 am, Alex White wrote: > v2: > - Replace tab expansion function in ReportsBase with std::string version > > This patch set includes a few improvements to the coverage reports. > > Alex White (4): > covoar/reports: Add new statistics to summa

Re: [PATCH 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

On 16/3/21 10:00 am, Joel Sherrill wrote: On Mon, Mar 15, 2021 at 5:58 PM Chris Johns > wrote: > On 16/3/21 9:11 am, Gedare Bloom wrote: > > On Mon, Mar 15, 2021 at 3:34 PM Alex White > >

Re: [PATCH 1/5] hexdump-parse.c: Fix Resource leak (CID #26032)

On 16/3/21 10:07 am, Joel Sherrill wrote: > 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 > >

Re: [PATCH 4/5] flashdisk.c: Fix Resource leak (CID #1439298)

On 15/3/21 2:21 pm, Joel Sherrill wrote: > 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/fl

Re: [PATCH 1/5] hexdump-parse.c: Fix Resource leak (CID #26032)

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 > > wrote: > > > > On Sun, Mar 14, 2021 at 8:27 PM Chris Johns > > wrote: > >

Re: [PATCH 1/5] hexdump-parse.c: Fix Resource leak (CID #26032)

On 16/3/21 6:55 am, Joel Sherrill wrote: > > > On Mon, Mar 15, 2021 at 2:46 PM Gedare Bloom > wrote: > > On Sun, Mar 14, 2021 at 8:27 PM Chris Johns > wrote: > > > > On 13/3/21 2:18 am, Ryan Long wrote: > > > CID 26032: Re

Re: [PATCH 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

On Mon, Mar 15, 2021 at 5:58 PM Chris Johns wrote: > On 16/3/21 9:11 am, Gedare Bloom wrote: > > On Mon, Mar 15, 2021 at 3:34 PM Alex White > > wrote: > > > > I honestly can't remember why I changed 1024 to 20,000. > > > > I've looked back at that code and

Re: [PATCH 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

On 16/3/21 9:11 am, Gedare Bloom wrote: > On Mon, Mar 15, 2021 at 3:34 PM Alex White > wrote: > > I honestly can't remember why I changed 1024 to 20,000. > > I've looked back at that code and changed it back to 1024 without any > issues. I think I might

Re: [PATCH 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

On 16/3/21 8:34 am, Alex White wrote: > I honestly can't remember why I changed 1024 to 20,000. > > I've looked back at that code and changed it back to 1024 without any issues. > I think I might have missed that this is all happening in a loop, and at one > point during a (long) debugging sessi

Re: [PATCH 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

On Mon, Mar 15, 2021 at 3:34 PM Alex White wrote: > I honestly can't remember why I changed 1024 to 20,000. > > I've looked back at that code and changed it back to 1024 without any > issues. I think I might have missed that this is all happening in a loop, > and at one point during a (long) debu

Re: [PATCH 3/5] nvdisk.c: Fix Resource leak (CID #1439297)

On Mon, Mar 15, 2021 at 2:28 PM Joel Sherrill wrote: > > > > 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/nvdis

[PATCH v2 2/4] coverage/reports: Improve formatting and clarity

The coverage reports contain places where they display incorrect or vague information particularly when some statistic is unavailable. This has been fixed. The formatting and wording of various things has been improved as well. --- tester/covoar/ObjdumpProcessor.cc | 5 + tester/covoar/ReportsBa

[PATCH v2 3/4] coverage/reports: Share common JS and CSS in reports

This moves all of the javascript and CSS files that are shared by the symbol set HTML reports to the shared parent directory. It also includes the javascript and CSS in the top-level index file. --- tester/covoar/ReportsHtml.cc | 4 ++-- tester/rt/coverage.py| 11 ++- 2 files chan

[PATCH v2 4/4] coverage: Give coverage bars red background

--- tester/rt/coverage.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py index ec3957c..a561d26 100644 --- a/tester/rt/coverage.py +++ b/tester/rt/coverage.py @@ -129,6 +129,9 @@ class report_gen_html: head_section += 'width: 150px

[PATCH v2 0/4] coverage/reports: Improve coverage reports

v2: - Replace tab expansion function in ReportsBase with std::string version This patch set includes a few improvements to the coverage reports. Alex White (4): covoar/reports: Add new statistics to summary coverage/reports: Improve formatting and clarity coverage/reports: Share common JS a

[PATCH v2 1/4] covoar/reports: Add new statistics to summary

The following new statistics have been added to the summary report: number of unreferenced symbols, total branch paths found, number of branch paths not executed, and percentage of branch paths covered. --- tester/covoar/DesiredSymbols.cc | 10 +++ tester/covoar/DesiredSymbols.h | 24

Re: [PATCH 1/2] objectextendinformation.c: Fix Dereference after null check (CID #26033)

On Mon, Mar 15, 2021 at 2:27 PM Joel Sherrill wrote: > > > > 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/s

Re: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq

Yeah go ahead, thanks Jan. On Mon, Mar 15, 2021 at 6:58 AM Joel Sherrill wrote: > > 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 >> >

Re: code reformatting was Re: Regarding gsoc project 3860

On Mon, Mar 15, 2021 at 6:44 AM Joel Sherrill wrote: > > > > On Mon, Mar 15, 2021 at 4:20 AM Hesham Almatary > wrote: >> >> Hello Ayushman and Ida, >> >> Usually, if multiple students really want to work on a particular >> project (and can't/don't want to choose another), there can be >> multipl

[PATCH v2] covoar: Handle periods in symbols from objdump

Occasionally the compiler will generate symbols that look similar to symbols defined in RTEMS code except that they contain some suffix. This looks to be related to compiler optimizations. Such symbols were being treated as unique. For our purposes, they should be mapped to the equivalent symbols i

Re: [PATCH 1/1] Edited hello world message in init.c as prerequisite for GSOC application.

Hi Matt, On Mon, Mar 15, 2021 at 2:50 PM Matt Joyce wrote: > > --- > testsuites/samples/hello/init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c > index 34ded37c55..48498fd52b 100644 > --- a/testsuite

RE: [PATCH 1/2] covoar/CoverageReaderQEMU: Fix infinite loop

I honestly can't remember why I changed 1024 to 20,000. I've looked back at that code and changed it back to 1024 without any issues. I think I might have missed that this is all happening in a loop, and at one point during a (long) debugging session I convinced myself that it wasn't reading al

RE: [PATCH] covoar: Handle periods in symbols from objdump

The exceptions are being used as legitimate error cases. The "what" messages that I use here are not helpful. I think that's why it looks like they're being used as labels. As part of a revision of my "covoar: Fix NOP execution marking" patch that I'll be sending out soon, this has been greatl

[Screenshot] Matt Joyce GSOC Hello World Patch

Hello RTEMS Community, Please find my attached screenshot for the GSOC Hello World introduction. Thank you again for your time! Sincerely, Matt ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/1] Edited hello world message in init.c as prerequisite for GSOC application.

--- testsuites/samples/hello/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c index 34ded37c55..48498fd52b 100644 --- a/testsuites/samples/hello/init.c +++ b/testsuites/samples/hello/init.c @@ -22,7 +22,7 @

[PATCH 0/1] Matt Joyce GSOC Hello World Patch

Hello RTEMS Community! Please see my Hello World patch as per the GSOC instructions. Thank you very much for your time and I'm excited to join you! Sincerely, Matt Matt Joyce (1): Edited hello world message in init.c as prerequisite for GSOC application. testsuites/samples/hello/init.c

Re: #3860 - GSoC enquiries

See the related thread, and we'll have to discuss how to move forward. The existing approach provides an uncrustify script: https://lists.rtems.org/pipermail/devel/2020-October/062769.html On Sun, Mar 14, 2021 at 9:47 PM Ida Delphine wrote: > > Hello everyone, > This ticket(https://devel.rtems.o

Re: [PATCH] rtems-examples: Add CoreMark Benchmark

On Mon, Mar 15, 2021 at 6:02 AM Joel Sherrill wrote: > > > > On Mon, Mar 15, 2021, 5:53 AM Hesham Almatary > wrote: >> >> Hello Gedare, >> >> Yeah adding Make support should be straightforward. I just assumed >> Make will be deprecated soon based on [1] and haven't bothered >> supporting it. >>

Re: Linking error with powerpc/beatnik

Hi Vijay, This seems like it could be a problem in the linkcmds, possibly in some missing KEEP() sections plus LTO? Check/compare the linkcmds between 6, 5, and 4.10 you might get some ideas. On Sun, Mar 14, 2021 at 9:27 PM Vijay Kumar Banerjee wrote: > > Hello, > > I'm trying to build EPICS7 wi

Re: [PATCH 3/5] nvdisk.c: Fix Resource leak (CID #1439297)

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(-) >

Re: [PATCH 1/2] objectextendinformation.c: Fix Dereference after null check (CID #26033)

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

Re: [PATCH] covoar: Fix null pointer dereference

ok -- imagine that, cleaning up resources in a destructor ;) On Fri, Mar 12, 2021 at 10:06 AM Alex White wrote: > > A null pointer dereference happens later in the program execution if > the files are cleaned up at the end of the ExecutableInfo constructor. > This change fixes the null pointer de

Re: [PATCH] score: Add Thread_Configuration::cpu_time_budget

looks good On Fri, Mar 12, 2021 at 12:34 AM Sebastian Huber wrote: > > Move the CPU time budget to the thread configuration. This simplifies > _Thread_Initialize(). > --- > cpukit/include/rtems/posix/pthreadimpl.h | 26 +++--- > cpukit/include/rtems/score/threadimpl.h | 5 +++ > cpuki

Re: [PATCH 1/2] objectextendinformation.c: Fix Dereference after null check (CID #26033)

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, 11 insertions(+) > > diff --git a/cpukit/score/src/objectextendinf

Re: [PATCH 3/5] nvdisk.c: Fix Resource leak (CID #1439297)

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(-) > > diff --git a/cpukit/libblock/src/nvdisk.c b/cpukit/libblock/src/nv

Re: [PATCH 2/5] rtems-fdt.c: Fix Resource leak (CID #1437645)

This one looks ok to me, Niteesh? On Fri, Mar 12, 2021 at 8:19 AM Ryan Long wrote: > > CID 1437645: Resource leak in rtems_fdt_load(). > > Closes #4297 > --- > cpukit/libmisc/rtems-fdt/rtems-fdt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c > b/

Re: [PATCH 0/4] Import and Port Beagle pinmux driver

Christian, Can you please provide comments on this patch series and the TI pinmux removal from libbsd? thanks On Sat, Mar 13, 2021 at 4:02 AM G S Niteesh Babu wrote: > > The following series of patches import and port the beagle > pinmux driver from FreeBSD to RTEMS. > > Porting this driver wil

Re: [PATCH v2] shell.c: Fix Dereference after null check (CID #26083)

On Sun, Mar 14, 2021 at 8:27 PM Chris Johns wrote: > > Sorry, this patch is blocked by the v1 thread. > +1 And why I asked about the "use cases" for this shell login. I guess those could be documented somewhere and some examples shown. > Chris > > On 12/3/21 9:17 am, Ryan Long wrote: > > CID 260

Re: [PATCH 6/6] rtems-docs: Edit commands to build first app

Hi Ida, On Mon, Mar 15, 2021 at 1:50 PM Gedare Bloom wrote: > > Hi Ida, > > did you send the same set of patches twice, or are there changes > between the two sets? > Since I'm not quite sure what to look at here, please do me a favor and send a new patchset with a -v2 indicator [1], and also se

Re: [PATCH 1/5] hexdump-parse.c: Fix Resource leak (CID #26032)

On Mon, Mar 15, 2021 at 2:46 PM Gedare Bloom wrote: > On Sun, Mar 14, 2021 at 8:27 PM Chris Johns wrote: > > > > On 13/3/21 2:18 am, Ryan Long wrote: > > > CID 26032: Resource leak in rtems_shell_hexdump_rewrite(). > > > > > > Closes #4296 > > > --- > > > cpukit/libmisc/shell/hexdump-parse.c |

Re: [PATCH 6/6] rtems-docs: Edit commands to build first app

Hi Ida, did you send the same set of patches twice, or are there changes between the two sets? On Sun, Mar 14, 2021 at 8:26 PM Ida Delphine wrote: > > --- > user/start/app.rst | 104 ++--- > 1 file changed, 52 insertions(+), 52 deletions(-) > > diff --git

Re: [PATCH 5/5] rtl-shell.c: Resource leak (CID #1444140)

On Sun, Mar 14, 2021 at 8:27 PM Chris Johns wrote: > > On 13/3/21 2:18 am, Ryan Long wrote: > > CID 1444140: Resource leak in rtems_rtl_shell_object(). > > > > Closes #4300 > > --- > > cpukit/libdl/rtl-shell.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/cpukit/libdl/rtl-shel

Re: [PATCH 1/5] hexdump-parse.c: Fix Resource leak (CID #26032)

On Sun, Mar 14, 2021 at 8:27 PM Chris Johns wrote: > > On 13/3/21 2:18 am, Ryan Long wrote: > > CID 26032: Resource leak in rtems_shell_hexdump_rewrite(). > > > > Closes #4296 > > --- > > cpukit/libmisc/shell/hexdump-parse.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/cpukit

[PATCH v4 1/2] covoar: Fix NOP execution marking

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/covoar/DesiredSymbols.cc | 38 +-- tester/covoar/Desi

[PATCH v4 0/2] Fix NOP recognition

v4: - Add specialized CoverageMapNotFoundError exception class to ExecutableInfo - Catch ExecutableInfo::CoverageMapNotFoundError in Coverage::finalizeSymbol() v3: - Fix double increment of rangeIndex in Coverage::finalizeSymbol() v2: - Fix leftover debugging code in Coverage::finalizeSymbol() T

[PATCH v4 2/2] covoar/Target_i386: Add NOP patterns

A couple of NOP patterns found with the pc686 BSP were not detected. This has been fixed. --- tester/covoar/Target_i386.cc | 9 + 1 file changed, 9 insertions(+) diff --git a/tester/covoar/Target_i386.cc b/tester/covoar/Target_i386.cc index e0c9c0f..4567c1e 100644 --- a/tester/covoar/Targ

RE: Flashdisk driver based on spidev

Thanks for all the pointers Chris, I will do some more research and see if I get a better idea how to go about this. Best regards, Jan > -Original Message- > From: Chris Johns > Sent: Wednesday, March 10, 2021 7:28 PM > To: Sommer, Jan ; devel@rtems.org > Subject: Re: Flashdisk driv

Re: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq

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

RE: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq

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: [PATCH v2] user/bsps: Mention fixed console baud rate for zynq > > --- > user/bsps/arm/xilinx-zynq.rst | 12 +

code reformatting was Re: Regarding gsoc project 3860

On Mon, Mar 15, 2021 at 4:20 AM Hesham Almatary < hesham.almat...@cl.cam.ac.uk> wrote: > Hello Ayushman and Ida, > > Usually, if multiple students really want to work on a particular > project (and can't/don't want to choose another), there can be > multiple proposals for the same project and we c

Re: [PATCH] rtems-examples: Add CoreMark Benchmark

On Mon, Mar 15, 2021, 5:53 AM Hesham Almatary wrote: > Hello Gedare, > > Yeah adding Make support should be straightforward. I just assumed > Make will be deprecated soon based on [1] and haven't bothered > supporting it. > > [1] > https://github.com/RTEMS/rtems-examples/blob/983926a7e519be85f630

Re: [PATCH] rtems-examples: Add CoreMark Benchmark

Hello Gedare, Yeah adding Make support should be straightforward. I just assumed Make will be deprecated soon based on [1] and haven't bothered supporting it. [1] https://github.com/RTEMS/rtems-examples/blob/983926a7e519be85f630c620430e7e1ac3e0f4ea/README.Makefile#L32 On Sun, 14 Mar 2021 at 1

Re: Regarding gsoc project 3860

Hello Ayushman and Ida, Usually, if multiple students really want to work on a particular project (and can't/don't want to choose another), there can be multiple proposals for the same project and we choose the best one. Sometimes a project can be split up between two students to work on to minimi

Re: Regarding gsoc project 3860

Umm...did you bring up a discussion regarding this project earlier? On Mon, 15 Mar 2021, 8:10 am Ayushman Mishra, wrote: > AYUSHMAN MISHRA > > Hello Ida delphini AYUSHMAN here , Can you please select any other project > for gsoc as I am also currently working on proposal for the same project > h

Regarding gsoc project 3860

AYUSHMAN MISHRA Hello Ida delphini AYUSHMAN here , Can you please select any other project for gsoc as I am also currently working on proposal for the same project https://devel.rtems.org/ticket/3860 for gsoc 2021 ___ devel mailing list devel@rtems.org h

Re: Current master fails make

Awesome, Thanks! On Mon, Mar 15, 2021 at 12:24 PM Amaan Cheval wrote: > Hey Richi, > > You probably need to upgrade and rebuild your toolchain using RSB to > support these new ftw.h related tests. > > See this relevant mail from the list announcing this: > https://lists.rtems.org/pipermail/users