Re: [rtems commit] Fix or1k C++ build failure
On Mon, Apr 27, 2015 at 7:48 AM, Sebastian Huber wrote: > I doubt that this fix is correct. This variable is usually defined in the > GCC libgcc/crtstuff.c file. I guess something is wrong with the GCC > configuration for this target. > I imitated what's in gdbv850sim/start/start.S. I'll check the GCC side. > On 26/04/15 21:56, Joel Sherril wrote: >> >> Module:rtems >> Branch:master >> Commit:3dead51eddcdb734b36c949cbc1e4c2cd21c52d4 >> Changeset: >> http://git.rtems.org/rtems/commit/?id=3dead51eddcdb734b36c949cbc1e4c2cd21c52d4 >> >> Author:Hesham ALMatary >> Date: Sun Apr 26 11:28:08 2015 -0500 >> >> Fix or1k C++ build failure >> >> >> Closes #2329 >> >> --- >> >> c/src/lib/libbsp/or1k/generic_or1k/start/start.S | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >> b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >> index d951a55..ae6d41a 100644 >> --- a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >> +++ b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >> @@ -180,3 +180,10 @@ _end_clear_bss: >> unhandled_exception: >> l.nop >> + >> +/* Make C++ compiler happy */ >> +.section .data >> +.global __dso_handle >> +.weak __dso_handle >> +__dso_handle: >> +.long 0 >> >> ___ >> vc mailing list >> v...@rtems.org >> http://lists.rtems.org/mailman/listinfo/vc > > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] Fix or1k C++ build failure
It's not defined anywhere at libgcc/config/or1k/crt*. I can add it to libgcc/config/or1k/crti.S but I'm not sure this will also be correct. On Mon, Apr 27, 2015 at 8:21 AM, Hesham ALMatary wrote: > On Mon, Apr 27, 2015 at 7:48 AM, Sebastian Huber > wrote: >> I doubt that this fix is correct. This variable is usually defined in the >> GCC libgcc/crtstuff.c file. I guess something is wrong with the GCC >> configuration for this target. >> > I imitated what's in gdbv850sim/start/start.S. I'll check the GCC side. >> On 26/04/15 21:56, Joel Sherril wrote: >>> >>> Module:rtems >>> Branch:master >>> Commit:3dead51eddcdb734b36c949cbc1e4c2cd21c52d4 >>> Changeset: >>> http://git.rtems.org/rtems/commit/?id=3dead51eddcdb734b36c949cbc1e4c2cd21c52d4 >>> >>> Author:Hesham ALMatary >>> Date: Sun Apr 26 11:28:08 2015 -0500 >>> >>> Fix or1k C++ build failure >>> >>> >>> Closes #2329 >>> >>> --- >>> >>> c/src/lib/libbsp/or1k/generic_or1k/start/start.S | 7 +++ >>> 1 file changed, 7 insertions(+) >>> >>> diff --git a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >>> b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >>> index d951a55..ae6d41a 100644 >>> --- a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >>> +++ b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >>> @@ -180,3 +180,10 @@ _end_clear_bss: >>> unhandled_exception: >>> l.nop >>> + >>> +/* Make C++ compiler happy */ >>> +.section .data >>> +.global __dso_handle >>> +.weak __dso_handle >>> +__dso_handle: >>> +.long 0 >>> >>> ___ >>> vc mailing list >>> v...@rtems.org >>> http://lists.rtems.org/mailman/listinfo/vc >> >> >> -- >> Sebastian Huber, embedded brains GmbH >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> Phone : +49 89 189 47 41-16 >> Fax : +49 89 189 47 41-09 >> E-Mail : sebastian.hu...@embedded-brains.de >> PGP : Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> > > > > -- > Hesham -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] Fix or1k C++ build failure
On 27/04/15 09:44, Hesham ALMatary wrote: It's not defined anywhere at libgcc/config/or1k/crt*. I can add it to libgcc/config/or1k/crti.S but I'm not sure this will also be correct. It is defined in libgcc/crtstuff.c. The target must define INIT_SECTION_ASM_OP or INIT_ARRAY_SECTION_ASM_OP somehow. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 Branching
On 27/04/15 03:15, Joel Sherrill wrote: I had the impression Sebastian wanted to merge one more patch set. Is this true? I checked in some fixes for the cache manager and the cache support for SPARC. That's all for now. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] [RSB] or1k: correct the md5 hash of the GCC patch
--- rtems/config/4.11/rtems-or1k.bset | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rtems/config/4.11/rtems-or1k.bset b/rtems/config/4.11/rtems-or1k.bset index b486885..2e6fb01 100644 --- a/rtems/config/4.11/rtems-or1k.bset +++ b/rtems/config/4.11/rtems-or1k.bset @@ -17,7 +17,7 @@ #gcc %patch add gcc -p1 https://raw.githubusercontent.com/heshamelmatary/or1k-rtems/master/patches/gcc-4.8.3-or1k-rtems-29072014.diff -%hash md5 gcc-4.8.3-or1k-rtems-29072014.diff df2555b2dd4de2d78366fabd705f36ac +%hash md5 gcc-4.8.3-or1k-rtems-29072014.diff 97be92fbe69a355625633a8d128fb5f5 #gdb %patch add gdb -p1 https://raw.githubusercontent.com/heshamelmatary/or1k-rtems/master/patches/gdb-7.7-or1k-rtems.diff -- 2.1.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Fix or1k C++ build failure
Will this fix global ctor/dtor's? (Tested e.g. by compiling and running testsuites/samples/cdtest in or1ksim.) Regards, /Emil Nordling On Mon, Apr 27, 2015 at 12:51 PM wrote: > Send devel mailing list submissions to > devel@rtems.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to > devel-requ...@rtems.org > > You can reach the person managing the list at > devel-ow...@rtems.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > > Today's Topics: > >1. [PATCH] Fix or1k C++ build failure (Hesham ALMatary) >2. 4.11 Branching (Joel Sherrill) >3. Re: 4.11 Branching (Chris Johns) >4. Re: 4.11 Branching (Joel Sherrill) >5. Re: [rtems commit] Fix or1k C++ build failure (Sebastian Huber) >6. Re: [rtems commit] Fix or1k C++ build failure (Hesham ALMatary) >7. Re: [rtems commit] Fix or1k C++ build failure (Hesham ALMatary) >8. Re: [rtems commit] Fix or1k C++ build failure (Sebastian Huber) >9. Re: 4.11 Branching (Sebastian Huber) > 10. [PATCH] [RSB] or1k: correct the md5 hash of the GCC patch > (Hesham ALMatary) > > > -- > > Message: 1 > Date: Sun, 26 Apr 2015 17:28:08 +0100 > From: Hesham ALMatary > To: devel@rtems.org > Subject: [PATCH] Fix or1k C++ build failure > Message-ID: > <1430065688-18143-1-git-send-email-heshamelmat...@gmail.com> > > Closes #2329 > --- > c/src/lib/libbsp/or1k/generic_or1k/start/start.S | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S > b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S > index d951a55..ae6d41a 100644 > --- a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S > +++ b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S > @@ -180,3 +180,10 @@ _end_clear_bss: > > unhandled_exception: >l.nop > + > +/* Make C++ compiler happy */ > +.section .data > +.global __dso_handle > +.weak __dso_handle > +__dso_handle: > +.long 0 > -- > 2.1.0 > > > > -- > > Message: 2 > Date: Sun, 26 Apr 2015 20:15:04 -0500 > From: Joel Sherrill > To: "devel@rtems.org" > Subject: 4.11 Branching > Message-ID: <2edd6976-780e-4172-b49f-f60d9e029...@oarcorp.com> > Content-Type: text/plain; charset="UTF-8" > > Hi > > I have a fix in the test queue for the build breakages I reported last > week. Hesham fixed C++ on the or1k. > > I need to bump the dates on the documentation before branching. > > I had the impression Sebastian wanted to merge one more patch set. Is this > true? > > Anything else? > --joel > > > -- > > Message: 3 > Date: Mon, 27 Apr 2015 11:41:34 +1000 > From: Chris Johns > To: Joel Sherrill , "devel@rtems.org" > > Subject: Re: 4.11 Branching > Message-ID: <553d93ce.9040...@rtems.org> > Content-Type: text/plain; charset=windows-1252 > > On 27/04/2015 11:15 am, Joel Sherrill wrote: > > > > Anything else? > > I have a change for the cpuuse top command to correctly display the > current usage rather than the total usage. This is not a bug fix as such > so I am not sure it is ok to go in. > > Chris > > > -- > > Message: 4 > Date: Sun, 26 Apr 2015 20:44:13 -0500 > From: Joel Sherrill > To: Chris Johns ,"devel@rtems.org" > Subject: Re: 4.11 Branching > Message-ID: <7d1ae1b5-1ed9-48c7-bce4-ed5927b64...@oarcorp.com> > Content-Type: text/plain; charset="UTF-8" > > > > On April 26, 2015 8:41:34 PM CDT, Chris Johns wrote: > >On 27/04/2015 11:15 am, Joel Sherrill wrote: > >> > >> Anything else? > > > >I have a change for the cpuuse top command to correctly display the > >current usage rather than the total usage. This is not a bug fix as > >such > >so I am not sure it is ok to go in. > > It's ok to merge it. Top is new so fixing something is ok. Just timing on > when it is ready. > > >Chris > > --joel > > > -- > > Message: 5 > Date: Mon, 27 Apr 2015 08:48:38 +0200 > From: Sebastian Huber > To: "rtems-de...@rtems.org" > Subject: Re: [rtems commit] Fix or1k C++ build failure > Message-ID: <553ddbc6.9040...@embedded-brains.de> > Content-Type: text/plain; charset=windows-1252; format=flowed > > I doubt that this fix is correct. This variable is usually defined in > the GCC libgcc/crtstuff.c file. I guess something is wrong with the GCC > configuration for this target. > > On 26/04/15 21:56, Joel Sherril wrote: > > Module:rtems > > Branch:master > > Commit:3dead51eddcdb734b36c949cbc1e4c2cd21c52d4 > > Changeset: > http://git.rtems.org/rtems/commit/?id=3dead51eddcdb734b36c949cbc1e4c2cd21c52d4 > > > > Author:Hesham ALMatary > > Date: Sun Apr 26 11:28:08 2015 -0500 > > > > Fix or1k C++ build failure > > > > Closes #2329 > > > > --- > > > > c/src/lib/libbsp/or1k
Re: [PATCH] Fix or1k C++ build failure
On Mon, Apr 27, 2015 at 12:17 PM, Emil Nordling wrote: > Will this fix global ctor/dtor's? (Tested e.g. by compiling and running > testsuites/samples/cdtest in or1ksim.) cdtest is built and compiled fine, it's also running but I'm not sure if it behaves properly. > > Regards, > /Emil Nordling > On Mon, Apr 27, 2015 at 12:51 PM wrote: >> >> Send devel mailing list submissions to >> devel@rtems.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.rtems.org/mailman/listinfo/devel >> or, via email, send a message with subject or body 'help' to >> devel-requ...@rtems.org >> >> You can reach the person managing the list at >> devel-ow...@rtems.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of devel digest..." >> >> >> Today's Topics: >> >>1. [PATCH] Fix or1k C++ build failure (Hesham ALMatary) >>2. 4.11 Branching (Joel Sherrill) >>3. Re: 4.11 Branching (Chris Johns) >>4. Re: 4.11 Branching (Joel Sherrill) >>5. Re: [rtems commit] Fix or1k C++ build failure (Sebastian Huber) >>6. Re: [rtems commit] Fix or1k C++ build failure (Hesham ALMatary) >>7. Re: [rtems commit] Fix or1k C++ build failure (Hesham ALMatary) >>8. Re: [rtems commit] Fix or1k C++ build failure (Sebastian Huber) >>9. Re: 4.11 Branching (Sebastian Huber) >> 10. [PATCH] [RSB] or1k: correct the md5 hash of the GCC patch >> (Hesham ALMatary) >> >> >> -- >> >> Message: 1 >> Date: Sun, 26 Apr 2015 17:28:08 +0100 >> From: Hesham ALMatary >> To: devel@rtems.org >> Subject: [PATCH] Fix or1k C++ build failure >> Message-ID: >> <1430065688-18143-1-git-send-email-heshamelmat...@gmail.com> >> >> Closes #2329 >> --- >> c/src/lib/libbsp/or1k/generic_or1k/start/start.S | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >> b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >> index d951a55..ae6d41a 100644 >> --- a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >> +++ b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S >> @@ -180,3 +180,10 @@ _end_clear_bss: >> >> unhandled_exception: >>l.nop >> + >> +/* Make C++ compiler happy */ >> +.section .data >> +.global __dso_handle >> +.weak __dso_handle >> +__dso_handle: >> +.long 0 >> -- >> 2.1.0 >> >> >> >> -- >> >> Message: 2 >> Date: Sun, 26 Apr 2015 20:15:04 -0500 >> From: Joel Sherrill >> To: "devel@rtems.org" >> Subject: 4.11 Branching >> Message-ID: <2edd6976-780e-4172-b49f-f60d9e029...@oarcorp.com> >> Content-Type: text/plain; charset="UTF-8" >> >> Hi >> >> I have a fix in the test queue for the build breakages I reported last >> week. Hesham fixed C++ on the or1k. >> >> I need to bump the dates on the documentation before branching. >> >> I had the impression Sebastian wanted to merge one more patch set. Is this >> true? >> >> Anything else? >> --joel >> >> >> -- >> >> Message: 3 >> Date: Mon, 27 Apr 2015 11:41:34 +1000 >> From: Chris Johns >> To: Joel Sherrill , "devel@rtems.org" >> >> Subject: Re: 4.11 Branching >> Message-ID: <553d93ce.9040...@rtems.org> >> Content-Type: text/plain; charset=windows-1252 >> >> On 27/04/2015 11:15 am, Joel Sherrill wrote: >> > >> > Anything else? >> >> I have a change for the cpuuse top command to correctly display the >> current usage rather than the total usage. This is not a bug fix as such >> so I am not sure it is ok to go in. >> >> Chris >> >> >> -- >> >> Message: 4 >> Date: Sun, 26 Apr 2015 20:44:13 -0500 >> From: Joel Sherrill >> To: Chris Johns ,"devel@rtems.org" >> Subject: Re: 4.11 Branching >> Message-ID: <7d1ae1b5-1ed9-48c7-bce4-ed5927b64...@oarcorp.com> >> Content-Type: text/plain; charset="UTF-8" >> >> >> >> On April 26, 2015 8:41:34 PM CDT, Chris Johns wrote: >> >On 27/04/2015 11:15 am, Joel Sherrill wrote: >> >> >> >> Anything else? >> > >> >I have a change for the cpuuse top command to correctly display the >> >current usage rather than the total usage. This is not a bug fix as >> >such >> >so I am not sure it is ok to go in. >> >> It's ok to merge it. Top is new so fixing something is ok. Just timing on >> when it is ready. >> >> >Chris >> >> --joel >> >> >> -- >> >> Message: 5 >> Date: Mon, 27 Apr 2015 08:48:38 +0200 >> From: Sebastian Huber >> To: "rtems-de...@rtems.org" >> Subject: Re: [rtems commit] Fix or1k C++ build failure >> Message-ID: <553ddbc6.9040...@embedded-brains.de> >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> I doubt that this fix is correct. This variable is usually defined in >> the GCC libgcc/crtstuff.c file. I guess something is wrong with the GCC >> configuration for this target. >> >> On 26/04/15 21:56, Joel Sherril wrote: >> > Module:rtems >> > Branch:master >> > Commit
Re: [PATCH] Fix or1k C++ build failure
Great! If I'm not mistaken, cdtest should mention calling global ctors, local ctors, local dtors and global dtors. Somewhere in between there is a section testing exceptions. If it ends with the "header"-printout for the exceptions, the global initialization is missing. Regards, /Emil Nordling On Mon, Apr 27, 2015 at 2:51 PM Hesham ALMatary wrote: > On Mon, Apr 27, 2015 at 12:17 PM, Emil Nordling > wrote: > > Will this fix global ctor/dtor's? (Tested e.g. by compiling and running > > testsuites/samples/cdtest in or1ksim.) > cdtest is built and compiled fine, it's also running but I'm not sure > if it behaves properly. > > > > Regards, > > /Emil Nordling > > On Mon, Apr 27, 2015 at 12:51 PM wrote: > >> > >> Send devel mailing list submissions to > >> devel@rtems.org > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> http://lists.rtems.org/mailman/listinfo/devel > >> or, via email, send a message with subject or body 'help' to > >> devel-requ...@rtems.org > >> > >> You can reach the person managing the list at > >> devel-ow...@rtems.org > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of devel digest..." > >> > >> > >> Today's Topics: > >> > >>1. [PATCH] Fix or1k C++ build failure (Hesham ALMatary) > >>2. 4.11 Branching (Joel Sherrill) > >>3. Re: 4.11 Branching (Chris Johns) > >>4. Re: 4.11 Branching (Joel Sherrill) > >>5. Re: [rtems commit] Fix or1k C++ build failure (Sebastian Huber) > >>6. Re: [rtems commit] Fix or1k C++ build failure (Hesham ALMatary) > >>7. Re: [rtems commit] Fix or1k C++ build failure (Hesham ALMatary) > >>8. Re: [rtems commit] Fix or1k C++ build failure (Sebastian Huber) > >>9. Re: 4.11 Branching (Sebastian Huber) > >> 10. [PATCH] [RSB] or1k: correct the md5 hash of the GCC patch > >> (Hesham ALMatary) > >> > >> > >> -- > >> > >> Message: 1 > >> Date: Sun, 26 Apr 2015 17:28:08 +0100 > >> From: Hesham ALMatary > >> To: devel@rtems.org > >> Subject: [PATCH] Fix or1k C++ build failure > >> Message-ID: > >> <1430065688-18143-1-git-send-email-heshamelmat...@gmail.com> > >> > >> Closes #2329 > >> --- > >> c/src/lib/libbsp/or1k/generic_or1k/start/start.S | 7 +++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S > >> b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S > >> index d951a55..ae6d41a 100644 > >> --- a/c/src/lib/libbsp/or1k/generic_or1k/start/start.S > >> +++ b/c/src/lib/libbsp/or1k/generic_or1k/start/start.S > >> @@ -180,3 +180,10 @@ _end_clear_bss: > >> > >> unhandled_exception: > >>l.nop > >> + > >> +/* Make C++ compiler happy */ > >> +.section .data > >> +.global __dso_handle > >> +.weak __dso_handle > >> +__dso_handle: > >> +.long 0 > >> -- > >> 2.1.0 > >> > >> > >> > >> -- > >> > >> Message: 2 > >> Date: Sun, 26 Apr 2015 20:15:04 -0500 > >> From: Joel Sherrill > >> To: "devel@rtems.org" > >> Subject: 4.11 Branching > >> Message-ID: <2edd6976-780e-4172-b49f-f60d9e029...@oarcorp.com> > >> Content-Type: text/plain; charset="UTF-8" > >> > >> Hi > >> > >> I have a fix in the test queue for the build breakages I reported last > >> week. Hesham fixed C++ on the or1k. > >> > >> I need to bump the dates on the documentation before branching. > >> > >> I had the impression Sebastian wanted to merge one more patch set. Is > this > >> true? > >> > >> Anything else? > >> --joel > >> > >> > >> -- > >> > >> Message: 3 > >> Date: Mon, 27 Apr 2015 11:41:34 +1000 > >> From: Chris Johns > >> To: Joel Sherrill , "devel@rtems.org" > >> > >> Subject: Re: 4.11 Branching > >> Message-ID: <553d93ce.9040...@rtems.org> > >> Content-Type: text/plain; charset=windows-1252 > >> > >> On 27/04/2015 11:15 am, Joel Sherrill wrote: > >> > > >> > Anything else? > >> > >> I have a change for the cpuuse top command to correctly display the > >> current usage rather than the total usage. This is not a bug fix as such > >> so I am not sure it is ok to go in. > >> > >> Chris > >> > >> > >> -- > >> > >> Message: 4 > >> Date: Sun, 26 Apr 2015 20:44:13 -0500 > >> From: Joel Sherrill > >> To: Chris Johns ,"devel@rtems.org" > >> Subject: Re: 4.11 Branching > >> Message-ID: <7d1ae1b5-1ed9-48c7-bce4-ed5927b64...@oarcorp.com> > >> Content-Type: text/plain; charset="UTF-8" > >> > >> > >> > >> On April 26, 2015 8:41:34 PM CDT, Chris Johns wrote: > >> >On 27/04/2015 11:15 am, Joel Sherrill wrote: > >> >> > >> >> Anything else? > >> > > >> >I have a change for the cpuuse top command to correctly display the > >> >current usage rather than the total usage. This is not a bug fix as > >> >such > >> >so I am not sure it is ok to go in. > >> > >> It's ok to merge it. Top is new so fixing something is ok. Just timing > on > >> when it i
GSoC projects announced
Congratulations to our accepted student projects. Students, please make sure you read your acceptance email carefully. For the Doodle note that the times listed are 10am to 3pm EDT (UTC-4). I'll be looking for one or two time slots that hopefully we can all meet. Past experience says the times closer to 10 or 11 am tend to work the best globally, with exception for Australia. Here are the accepted projects: FRAMEBUFFER AND HDMI VIDEO SUPPORT FOR RPI YANG QIAO Porting Monkey HTTP server to RTEMS Sujay Raj Nested Mutexes Saurabh Gadia Beagle BSP Improvements ragunath Raspberry Pi 2 Support Rohini Kulkarni Beagleboard BSP Improvement ketul Beagle BSP improvements: Porting MicroMonitor to boot without U-boot jrcatbagan Raspberry Pi BSB USB support Yurii Shevtsov Raspberry Pi Low Level Peripherals and SD Card Andre Marques Configuration GUI anandkp92 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] libmisc/cpuuse: Top support for current load.
The cpuuse top command now supports the current load where the list of
tasks is ordered based on the current load rather than the total cpu usage.
This lets you see what is using the processor at any specific instance. You
can toggle between the modes.
Added memory usage stats for unified and separate workspace and C heaps as
well as displaying the allocated stack space.
Added a few more command keys to refresh the display, show all tasks in the
system, control the lines display and a scrolling mode that does not clear
the display on each refresh.
Removed support for tick kernel builds. The tick support in the kernel is to
be removed.
---
cpukit/libmisc/cpuuse/cpuusagetop.c | 691 ++--
1 file changed, 496 insertions(+), 195 deletions(-)
diff --git a/cpukit/libmisc/cpuuse/cpuusagetop.c
b/cpukit/libmisc/cpuuse/cpuusagetop.c
index e47ba59..13b659e 100644
--- a/cpukit/libmisc/cpuuse/cpuusagetop.c
+++ b/cpukit/libmisc/cpuuse/cpuusagetop.c
@@ -18,6 +18,7 @@
#include "config.h"
#endif
+#include
#include
#include
#include
@@ -25,29 +26,97 @@
#include
#include
+#include
#include
+#include
#include
#include
#include
+#include
/*
* Common variable to sync the load monitor task.
*/
-static volatile int rtems_cpuusage_top_thread_active;
-
-typedef struct {
- void *context;
+typedef struct
+{
+ void* context;
rtems_printk_plugin_t print;
-}rtems_cpu_usage_plugin_t;
+} rtems_cpu_usage_plugin;
+
+/*
+ * Use a struct for all data to allow more than one top and to support the
+ * thread iterator.
+ */
+typedef struct
+{
+ volatile bool thread_run;
+ volatile bool thread_active;
+ volatile bool single_page;
+ volatile bool sort_current;
+ volatile uint32_t poll_rate_usecs;
+ volatile uint32_t show;
+ rtems_cpu_usage_plugin plugin;
+ Thread_CPU_usage_t zero;
+ Timestamp_Control uptime;
+ Timestamp_Control last_uptime;
+ Timestamp_Control period;
+ inttask_count;/* Number of tasks. */
+ intlast_task_count; /* Number of tasks in the previous
sample. */
+ inttask_size; /* The size of the arrays */
+ Thread_Control** tasks; /* List of tasks in this sample. */
+ Thread_Control** last_tasks;/* List of tasks in the last
sample. */
+ Thread_CPU_usage_t*usage; /* Usage of task's in this sample.
*/
+ Thread_CPU_usage_t*last_usage;/* Usage of task's in the last
sample. */
+ Thread_CPU_usage_t*current_usage; /* Current usage for this sample.
*/
+ Timestamp_Control total; /* Total run run, should equal the
uptime. */
+ Timestamp_Control idle; /* Time spent in idle. */
+ Timestamp_Control current; /* Current time run in this
period. */
+ Timestamp_Control current_idle; /* Current time in idle this
period. */
+ uint32_t stack_size;/* Size of stack allocated. */
+} rtems_cpu_usage_data;
+
+/*
+ * Private version of the iterator with an arg. This will be moved
+ * to the public in 5.0.
+ */
+
+typedef void (*rtems_per_thread_routine_2)( Thread_Control *, void* );
-#define RTEMS_CPUUSAGE_TOP_MAX_LOAD_TASKS (20)
+void rtems_iterate_over_all_threads_2(rtems_per_thread_routine_2 routine,
+ void* arg);
+void rtems_iterate_over_all_threads_2(rtems_per_thread_routine_2 routine,
+ void* arg)
+{
+ uint32_t i;
+ uint32_t api_index;
+ Thread_Control *the_thread;
+ Objects_Information *information;
+
+ if ( !routine )
+return;
+
+ for ( api_index = 1 ; api_index <= OBJECTS_APIS_LAST ; api_index++ ) {
+#if !defined(RTEMS_POSIX_API) || defined(RTEMS_DEBUG)
+ if ( !_Objects_Information_table[ api_index ] )
+continue;
+#endif
+information = _Objects_Information_table[ api_index ][ 1 ];
+if ( information ) {
+ for ( i=1 ; i <= information->maximum ; i++ ) {
+the_thread = (Thread_Control *)information->local_table[ i ];
+if ( the_thread )
+ (*routine)(the_thread, arg);
+ }
+}
+ }
+}
static inline bool equal_to_uint32_t( uint32_t * lhs, uint32_t * rhs )
{
if ( *lhs == *rhs )
return true;
- else
+ else
return false;
}
@@ -60,31 +129,163 @@ static inline bool less_than_uint32_t( uint32_t * lhs,
uint32_t * rhs )
}
#ifndef __RTEMS_USE_TICKS_FOR_STATISTICS__
- #define _Thread_CPU_usage_Equal_to( _lhs, _rhs ) \
+ #define CPU_usage_Equal_to( _lhs, _rhs ) \
_Timestamp_Equal_to( _lhs, _rhs )
#else
- #define _Thread_CPU_usage_Equal_to( _lhs, _rhs ) \
+ #define CPU_usage_Equal_to( _lhs, _rhs ) \
equal_to_uint32_t( _lhs, _rhs )
#endif
#ifndef __RTEMS_USE_TI
