Re: Tickets: Milestone vs. Version
On Fri, Aug 10, 2018 at 2:10 AM, Chris Johns wrote: > > Release Terminology > > - A release is the creation of any generated files and their packaging > together > with the source in a repository that makes the package available as a file. > - A release branch is a git branch pushed to the repositories used to create > release. There is a release branch for each version of RTEMS. > - A release is a git tag on a release branch with the tags pushed to the > repositories. > > ? This may be a separate discussion. Here you defined 'release' twice, so I'm a bit unclear about your proposed terminology. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tickets: Milestone vs. Version
On Fri, Aug 10, 2018 at 2:10 AM, Chris Johns wrote: > On 10/08/2018 15:41, Sebastian Huber wrote: >> On 10/08/18 07:38, Chris Johns wrote: >>> On 10/08/2018 15:03, Sebastian Huber wrote: we want a ticket for each milestone in which it is resolved. What is now the meaning of the version field? >>> A ticket may be assigned to a branch but not a milestone. Milestones lets us >>> select which tickets we fix on branch. Once all tickets on a milestone are >>> closed the release can be made. >>> >>> We do not work that way at the moment. I use the milestones when making >>> releases >>> to move tickets scheduled for a release that are not closed to the next >>> release. >> >> This doesn't explain the version field. Is version the same as branch from >> your >> point of view? >> > > The branch is the version of RTEMS released from that branch. In trac it is > called version, ie 4.11, 4.10, 5 etc. The term version is more accurate, the > use > of branch is actually a VC implementation detail. > I had understood we should use 'version' field in Trac to indicate when the bug first appeared. If this is not the case, then definitely (a) we need more guidance, and (b) we probably need a way to indicate (our best guess about) when a bug appeared. Gedare ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs
Haha, don't worry about it. It's really a non-blocker we can absolutely handle after GSoC just as well. I just wanted to confirm in case I'd missed something! On Fri, Aug 10, 2018 at 6:55 PM, Joel Sherrill wrote: > I am sorry. I will have to dig this up and commit it. > > I will try to do this before I leave about lunch. > > Looks like we both have work to do before the end of GSoC. :) > > --joel > > On Fri, Aug 10, 2018 at 6:11 AM, Amaan Cheval > wrote: >> >> Hey Joel! >> >> I'm not sure if this ever made it upstream - if it did, could you dig >> the commit up? >> >> I'll leave the x86_64's bsp_specs empty and make the RSB backporting >> patches accordingly. If not, no rush, we should just add a ticket or >> something so as to not lose track of it entirely after GSoC ends. >> >> On Mon, Jul 9, 2018 at 10:30 AM, Amaan Cheval >> wrote: >> > To make my previous email clearer, here's what I meant with the >> > "minimal" GCC patch required (attached). >> > >> > To manually test, you can place gcc-STARTFILE_SPEC.patch in >> > $RSB/rtems/patches/ and then "git apply rsb-startfile.diff" to the RSB >> > repo. Then build GCC and confirm that "x86_64-rtems5-gcc -dumpspecs" >> > includes crti and crtbegin in the startfile susbtitution. >> > >> > Let me know if we aim to have this GCC work done before merging the >> > x86_64 BSP (see >> > https://lists.rtems.org/pipermail/devel/2018-July/022388.html) so I >> > can leave bsp_specs in or clear it out accordingly? >> > >> > For now, I'm going to leave it in. >> > >> > On Fri, Jul 6, 2018 at 10:46 AM, Amaan Cheval >> > wrote: >> >> Hey, Joel! >> >> >> >> The x86_64 BSP currently uses an empty bsp_specs file contingent on >> >> (at least the x86-64 parts of) this email thread's patch making it >> >> upstream to GCC, and making their way into the RSB. >> >> >> >> 2 options: >> >> - 1. Make the upstream GCC commit (at least the parts adding >> >> rtemself64.h, editing config.gcc, and "#if 0"ing out >> >> gcc/config/rtems.h) >> >> - 2. Use a bsp_specs in the new BSP for the merge now, and empty it out >> >> later >> >> >> >> I can test and send you an x86_64 specific patch for GCC if you'd >> >> like. Or if you prefer to have all the work together, we can go with >> >> #2. >> >> >> >> Let me know! >> >> >> >> On Sat, May 19, 2018 at 3:17 AM, Joel Sherrill wrote: >> >>> Thanks. I will try to deal with this Monday. >> >>> >> >>> My specs patches are not ready to push to gcc so I need to focus on >> >>> just the parts to make x86_64 right. >> >>> >> >>> On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval >> >>> wrote: >> >> To be clear, I applied this patch (with my fixes) on the 7.3 release >> through the RSB to test, not on GCC's master branch. >> >> > to add i386/rtemself64.h >> >> What you sent in this email thread adds rtemself64.h already. Do you >> mean you'd like to split the commits up or something? >> >> The only changes I made on top of yours were: >> >> - Readd "rtems.h" to config.gcc >> - Fix comments >> >> I've attached the patch file I used within the RSB here (sorry if you >> meant a patch of _just_ the fixes I made on top of yours, this is >> just >> the cumulative diff I used to patch GCC 7.3 to test). >> >> Regards, >> >> On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill >> wrote: >> > >> > >> > >> > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval >> > >> > wrote: >> >> >> >> I just compiled my local fixed copy (adding rtems.h back in) and >> >> there's good news! With the patch, the x86_64 compile stub works >> >> with >> >> a blank bsp_specs file! >> > >> > >> > Awesome! >> > >> > Can you send me your changes as a patch? I am thinking I need to >> > make >> > sure we agree on what the gcc master for x86_64-rtems looks like. >> > >> > Apparently I owe committing a patch to add i386/rtemself64.h since >> > it is >> > missing on the master. And the comment is wrong. What else? >> > >> >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval >> >> >> >> wrote: >> >> > Hey! >> >> > >> >> > Thanks so much for sharing this, it's quite useful to put your >> >> > earlier >> >> > email[1] about minimzing the bsp_specs in context. >> >> > >> >> > From looking ahead a bit without testing (still compiling), the >> >> > patch >> >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it >> >> > defines >> >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and >> >> > possibly >> >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs >> >> > entirely >> >> > (see here[2]). >> >> >> >> Just noticed that ENDFILE_SPEC already includes crtend in >> >> i386elf.h, >> >> so there's no need for this change. >> >> >>
[PATCH 08/10] qoriq/include/tm27.h: Fix prototype warning
---
bsps/powerpc/qoriq/include/tm27.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bsps/powerpc/qoriq/include/tm27.h
b/bsps/powerpc/qoriq/include/tm27.h
index 46264b7..79ef3b4 100644
--- a/bsps/powerpc/qoriq/include/tm27.h
+++ b/bsps/powerpc/qoriq/include/tm27.h
@@ -78,12 +78,12 @@ static void qoriq_tm27_cause(uint32_t ipi_index)
qoriq.pic.per_cpu[self].ipidr[ipi_index].reg = UINT32_C(1) << self;
}
-static void Cause_tm27_intr()
+static void Cause_tm27_intr(void)
{
qoriq_tm27_cause(IPI_INDEX_LOW);
}
-static void Clear_tm27_intr()
+static void Clear_tm27_intr(void)
{
/* Nothing to do */
}
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 09/10] bsps/sparc/include/bsp/gradcdac.h: Fix nested comment warning
--- bsps/sparc/include/bsp/gradcdac.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/sparc/include/bsp/gradcdac.h b/bsps/sparc/include/bsp/gradcdac.h index b520778..31facc2 100644 --- a/bsps/sparc/include/bsp/gradcdac.h +++ b/bsps/sparc/include/bsp/gradcdac.h @@ -1,5 +1,5 @@ /* ADC / DAC (GRADCDAC) interface -/* + * * COPYRIGHT (c) 2009. * Cobham Gaisler AB. * -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 10/10] libtests/POSIX: Fix warnings and style.
---
testsuites/libtests/POSIX/close.c | 4 +---
testsuites/libtests/POSIX/dup2.c | 4 +---
testsuites/libtests/POSIX/fcntl.c | 13 -
testsuites/libtests/POSIX/flockfile.c | 1 +
testsuites/libtests/POSIX/fork.c | 6 --
testsuites/libtests/POSIX/free.c | 5 ++---
testsuites/libtests/POSIX/fstat.c | 9 +
testsuites/libtests/POSIX/ftrylockfile.c | 4 +++-
testsuites/libtests/POSIX/funlockfile.c| 1 +
testsuites/libtests/POSIX/getdents.c | 6 +++---
testsuites/libtests/POSIX/getlogin.c | 5 +++--
testsuites/libtests/POSIX/getpwnam.c | 8
testsuites/libtests/POSIX/getpwuid.c | 3 +--
testsuites/libtests/POSIX/gettimeofday.c | 3 +--
testsuites/libtests/POSIX/getuid.c | 7 +++
testsuites/libtests/POSIX/htonl.c | 7 +--
testsuites/libtests/POSIX/iconv.c | 5 ++---
testsuites/libtests/POSIX/iconv_close.c| 5 ++---
testsuites/libtests/POSIX/iconv_open.c | 5 ++---
testsuites/libtests/POSIX/issetugid.c | 7 +++
testsuites/libtests/POSIX/kill.c | 16 ++--
testsuites/libtests/POSIX/longjmp.c| 5 ++---
testsuites/libtests/POSIX/lseek.c | 14 +-
testsuites/libtests/POSIX/lstat.c | 7 +++
testsuites/libtests/POSIX/malloc.c | 5 ++---
testsuites/libtests/POSIX/nanosleep.c | 7 +++
testsuites/libtests/POSIX/open.c | 9 -
testsuites/libtests/POSIX/pipe.c | 7 +++
testsuites/libtests/POSIX/posix_memalign.c | 5 ++---
testsuites/libtests/POSIX/read.c | 7 +++
testsuites/libtests/POSIX/readv.c | 5 ++---
testsuites/libtests/POSIX/realloc.c| 7 +++
testsuites/libtests/POSIX/setjmp.c | 5 ++---
testsuites/libtests/POSIX/sigaddset.c | 5 ++---
testsuites/libtests/POSIX/sigdelset.c | 5 ++---
testsuites/libtests/POSIX/sigemptyset.c| 5 ++---
testsuites/libtests/POSIX/sigfillset.c | 5 ++---
testsuites/libtests/POSIX/sigismember.c| 3 +--
testsuites/libtests/POSIX/sigprocmask.c| 17 ++---
testsuites/libtests/POSIX/stat.c | 7 +++
testsuites/libtests/POSIX/unlink.c | 4 ++--
testsuites/libtests/POSIX/vfork.c | 7 +++
testsuites/libtests/POSIX/wait.c | 5 ++---
testsuites/libtests/POSIX/waitpid.c| 6 +++---
testsuites/libtests/POSIX/write.c | 7 +++
testsuites/libtests/POSIX/writev.c | 5 ++---
46 files changed, 140 insertions(+), 148 deletions(-)
diff --git a/testsuites/libtests/POSIX/close.c
b/testsuites/libtests/POSIX/close.c
index 5468adc..b770a76 100644
--- a/testsuites/libtests/POSIX/close.c
+++ b/testsuites/libtests/POSIX/close.c
@@ -15,7 +15,5 @@
int
main (void)
{
- close (42);
-
- return 0;
+ return close(42);
}
diff --git a/testsuites/libtests/POSIX/dup2.c b/testsuites/libtests/POSIX/dup2.c
index b090d63..2e5238e 100644
--- a/testsuites/libtests/POSIX/dup2.c
+++ b/testsuites/libtests/POSIX/dup2.c
@@ -18,7 +18,5 @@ main (void)
int oldfd = 42;
int newfd = 43;
- dup2 (oldfd, newfd);
-
- return 0;
+ return dup2 (oldfd, newfd);
}
diff --git a/testsuites/libtests/POSIX/fcntl.c
b/testsuites/libtests/POSIX/fcntl.c
index dc59d5d..9578df4 100644
--- a/testsuites/libtests/POSIX/fcntl.c
+++ b/testsuites/libtests/POSIX/fcntl.c
@@ -13,11 +13,14 @@
#include
#include
-int
-main (void)
+int main (void)
{
- fcntl (42, 43);
- fcntl (42, 43, 44);
+ int rc;
- return 0;
+ rc = fcntl (42, 43);
+ (void) rc;
+
+ rc = fcntl (42, 43, 44);
+
+ return rc;
}
diff --git a/testsuites/libtests/POSIX/flockfile.c
b/testsuites/libtests/POSIX/flockfile.c
index 4d1f23e..01e322c 100644
--- a/testsuites/libtests/POSIX/flockfile.c
+++ b/testsuites/libtests/POSIX/flockfile.c
@@ -15,6 +15,7 @@
int main(void)
{
FILE *file = NULL;
+
flockfile(file);
return 0;
}
diff --git a/testsuites/libtests/POSIX/fork.c b/testsuites/libtests/POSIX/fork.c
index d4392be..e6e233f 100644
--- a/testsuites/libtests/POSIX/fork.c
+++ b/testsuites/libtests/POSIX/fork.c
@@ -15,7 +15,9 @@
int
main (void)
{
- fork ();
+ int rc;
- return 0;
+ rc = fork();
+
+ return rc;
}
diff --git a/testsuites/libtests/POSIX/free.c b/testsuites/libtests/POSIX/free.c
index 8473084..8550eaa 100644
--- a/testsuites/libtests/POSIX/free.c
+++ b/testsuites/libtests/POSIX/free.c
@@ -12,10 +12,9 @@
#include
-int
-main (void)
+int main (void)
{
- free ((void *) 42);
+ free((void *) 42);
return 0;
}
diff --git a/testsuites/libtests/POSIX/fstat.c
b/testsuites/libtests/POSIX/fstat.c
index 29c38d6..2798365 100644
--- a/testsuites/libtests/POSIX/fstat.c
+++ b/testsuites/libtests/POSIX/fstat.c
@@ -14,12 +14,13 @@
#include
#include
-int
-main (void)
+int main (void)
{
struct stat buf;
int fd = 42;
- fstat (fd, );
+ int rc;
- return 0;
+ rc =
[PATCH 03/10] gen5200/include/tm27.h: Fix prototype warning
---
bsps/powerpc/gen5200/include/tm27.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bsps/powerpc/gen5200/include/tm27.h
b/bsps/powerpc/gen5200/include/tm27.h
index ff43cc9..583aaa4 100644
--- a/bsps/powerpc/gen5200/include/tm27.h
+++ b/bsps/powerpc/gen5200/include/tm27.h
@@ -26,14 +26,14 @@
#define MUST_WAIT_FOR_INTERRUPT 1
-void nullFunc() {}
+void nullFunc(void) {}
static rtems_irq_connect_data clockIrqData = {BSP_DECREMENTER,
0,
- (rtems_irq_enable)nullFunc,
- (rtems_irq_disable)nullFunc,
+ (rtems_irq_enable) nullFunc,
+ (rtems_irq_disable) nullFunc,
(rtems_irq_is_enabled) nullFunc};
-void Install_tm27_vector(void (*_handler)())
+static void Install_tm27_vector(void (*_handler)(void))
{
clockIrqData.hdl = _handler;
if (!BSP_install_rtems_irq_handler ()) {
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 04/10] gen83xx/include/tm27.h: Fix prototype warning
---
bsps/powerpc/gen83xx/include/tm27.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/powerpc/gen83xx/include/tm27.h
b/bsps/powerpc/gen83xx/include/tm27.h
index 2278747..3728e7d 100644
--- a/bsps/powerpc/gen83xx/include/tm27.h
+++ b/bsps/powerpc/gen83xx/include/tm27.h
@@ -38,7 +38,7 @@ static int tm27_exception_handler( BSP_Exception_frame
*frame, unsigned number)
return 0;
}
-void Install_tm27_vector( void (*handler)(rtems_vector_number))
+static void Install_tm27_vector( void (*handler)(rtems_vector_number))
{
int rv = 0;
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 07/10] motorola_powerpc/include/tm27.h: Fix prototype warning
---
bsps/powerpc/motorola_powerpc/include/tm27.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bsps/powerpc/motorola_powerpc/include/tm27.h
b/bsps/powerpc/motorola_powerpc/include/tm27.h
index 81eb55a..4d616cb 100644
--- a/bsps/powerpc/motorola_powerpc/include/tm27.h
+++ b/bsps/powerpc/motorola_powerpc/include/tm27.h
@@ -25,13 +25,13 @@
#define MUST_WAIT_FOR_INTERRUPT 1
-void nullFunc() {}
+void nullFunc(void) {}
static rtems_irq_connect_data clockIrqData = {BSP_DECREMENTER,
0,
- (rtems_irq_enable)nullFunc,
- (rtems_irq_disable)nullFunc,
+ (rtems_irq_enable) nullFunc,
+ (rtems_irq_disable) nullFunc,
(rtems_irq_is_enabled) nullFunc};
-void Install_tm27_vector(void (*_handler)())
+static void Install_tm27_vector(void (*_handler)(void))
{
clockIrqData.hdl = _handler;
if (!BSP_install_rtems_irq_handler ()) {
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 01/10] csb337/include/at91rm9200_dbgu.h: Fix nested comment warning
--- bsps/arm/csb337/include/at91rm9200_dbgu.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/arm/csb337/include/at91rm9200_dbgu.h b/bsps/arm/csb337/include/at91rm9200_dbgu.h index 9a65483..250e013 100644 --- a/bsps/arm/csb337/include/at91rm9200_dbgu.h +++ b/bsps/arm/csb337/include/at91rm9200_dbgu.h @@ -56,7 +56,7 @@ #define DBGU_INT_RXRDY BIT0/* RXRDY Interrupt */ #define DBGU_INT_TXRDY BIT1/* TXRDY Interrupt */ #define DBGU_INT_ENDRX BIT3/* End of Receive Transfer Interrupt */ -/*efine DBGU_INT_ENDTX BIT4/* End of Transmit Interrupt */ +#define DBGU_INT_ENDTX BIT4/* End of Transmit Interrupt */ #define DBGU_INT_OVRE BIT5/* Overrun Interrupt */ #define DBGU_INT_FRAME BIT6/* Framing Error Interrupt */ #define DBGU_INT_PARE BIT7/* Parity Error Interrupt */ -- 1.8.3.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 02/10] gen5200/include/bsp/ata.h: Fix warning
---
bsps/powerpc/gen5200/include/bsp/ata.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/bsps/powerpc/gen5200/include/bsp/ata.h
b/bsps/powerpc/gen5200/include/bsp/ata.h
index 3d8ccfc..4b31ade 100644
--- a/bsps/powerpc/gen5200/include/bsp/ata.h
+++ b/bsps/powerpc/gen5200/include/bsp/ata.h
@@ -254,12 +254,14 @@ static inline void ata_driver_lock(const ata_driver *self)
{
rtems_status_code sc = rtems_semaphore_obtain(self->lock, RTEMS_WAIT,
RTEMS_NO_TIMEOUT);
assert(sc == RTEMS_SUCCESSFUL);
+ (void) sc;
}
static inline void ata_driver_unlock(const ata_driver *self)
{
rtems_status_code sc = rtems_semaphore_release(self->lock);
assert(sc == RTEMS_SUCCESSFUL);
+ (void) sc;
}
static inline bool ata_driver_is_card_present(const ata_driver *self)
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 05/10] bsps/powerpc/include/bsp/tictac.h: Fix protototype warnings
---
bsps/powerpc/include/bsp/tictac.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/bsps/powerpc/include/bsp/tictac.h
b/bsps/powerpc/include/bsp/tictac.h
index 31c7386..c8acf98 100644
--- a/bsps/powerpc/include/bsp/tictac.h
+++ b/bsps/powerpc/include/bsp/tictac.h
@@ -22,7 +22,7 @@
/**
* @brief Reset reference ticks for tac().
*/
-static inline void tic()
+static inline void tic(void)
{
uint32_t tmp;
asm volatile (
@@ -35,7 +35,7 @@ static inline void tic()
/**
* @brief Returns number of ticks since last tic().
*/
-static inline uint32_t tac()
+static inline uint32_t tac(void)
{
uint32_t ticks;
uint32_t tmp;
@@ -51,7 +51,7 @@ static inline uint32_t tac()
/**
* @brief Reset reference ticks for bam().
*/
-static inline void boom()
+static inline void boom(void)
{
uint32_t tmp;
asm volatile (
@@ -64,7 +64,7 @@ static inline void boom()
/**
* @brief Returns number of ticks since last boom().
*/
-static inline uint32_t bam()
+static inline uint32_t bam(void)
{
uint32_t ticks;
uint32_t tmp;
--
1.8.3.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs
I am sorry. I will have to dig this up and commit it. I will try to do this before I leave about lunch. Looks like we both have work to do before the end of GSoC. :) --joel On Fri, Aug 10, 2018 at 6:11 AM, Amaan Cheval wrote: > Hey Joel! > > I'm not sure if this ever made it upstream - if it did, could you dig > the commit up? > > I'll leave the x86_64's bsp_specs empty and make the RSB backporting > patches accordingly. If not, no rush, we should just add a ticket or > something so as to not lose track of it entirely after GSoC ends. > > On Mon, Jul 9, 2018 at 10:30 AM, Amaan Cheval > wrote: > > To make my previous email clearer, here's what I meant with the > > "minimal" GCC patch required (attached). > > > > To manually test, you can place gcc-STARTFILE_SPEC.patch in > > $RSB/rtems/patches/ and then "git apply rsb-startfile.diff" to the RSB > > repo. Then build GCC and confirm that "x86_64-rtems5-gcc -dumpspecs" > > includes crti and crtbegin in the startfile susbtitution. > > > > Let me know if we aim to have this GCC work done before merging the > > x86_64 BSP (see > > https://lists.rtems.org/pipermail/devel/2018-July/022388.html) so I > > can leave bsp_specs in or clear it out accordingly? > > > > For now, I'm going to leave it in. > > > > On Fri, Jul 6, 2018 at 10:46 AM, Amaan Cheval > wrote: > >> Hey, Joel! > >> > >> The x86_64 BSP currently uses an empty bsp_specs file contingent on > >> (at least the x86-64 parts of) this email thread's patch making it > >> upstream to GCC, and making their way into the RSB. > >> > >> 2 options: > >> - 1. Make the upstream GCC commit (at least the parts adding > >> rtemself64.h, editing config.gcc, and "#if 0"ing out > >> gcc/config/rtems.h) > >> - 2. Use a bsp_specs in the new BSP for the merge now, and empty it out > later > >> > >> I can test and send you an x86_64 specific patch for GCC if you'd > >> like. Or if you prefer to have all the work together, we can go with > >> #2. > >> > >> Let me know! > >> > >> On Sat, May 19, 2018 at 3:17 AM, Joel Sherrill wrote: > >>> Thanks. I will try to deal with this Monday. > >>> > >>> My specs patches are not ready to push to gcc so I need to focus on > >>> just the parts to make x86_64 right. > >>> > >>> On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval > >>> wrote: > > To be clear, I applied this patch (with my fixes) on the 7.3 release > through the RSB to test, not on GCC's master branch. > > > to add i386/rtemself64.h > > What you sent in this email thread adds rtemself64.h already. Do you > mean you'd like to split the commits up or something? > > The only changes I made on top of yours were: > > - Readd "rtems.h" to config.gcc > - Fix comments > > I've attached the patch file I used within the RSB here (sorry if you > meant a patch of _just_ the fixes I made on top of yours, this is just > the cumulative diff I used to patch GCC 7.3 to test). > > Regards, > > On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill > wrote: > > > > > > > > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval < > amaan.che...@gmail.com> > > wrote: > >> > >> I just compiled my local fixed copy (adding rtems.h back in) and > >> there's good news! With the patch, the x86_64 compile stub works > with > >> a blank bsp_specs file! > > > > > > Awesome! > > > > Can you send me your changes as a patch? I am thinking I need to > make > > sure we agree on what the gcc master for x86_64-rtems looks like. > > > > Apparently I owe committing a patch to add i386/rtemself64.h since > it is > > missing on the master. And the comment is wrong. What else? > > > >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval < > amaan.che...@gmail.com> > >> wrote: > >> > Hey! > >> > > >> > Thanks so much for sharing this, it's quite useful to put your > >> > earlier > >> > email[1] about minimzing the bsp_specs in context. > >> > > >> > From looking ahead a bit without testing (still compiling), the > patch > >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it > >> > defines > >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and > possibly > >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs > entirely > >> > (see here[2]). > >> > >> Just noticed that ENDFILE_SPEC already includes crtend in > i386elf.h, > >> so there's no need for this change. > >> > >> > > >> > I've also left some comments inline below. > >> > > >> > +1 on upstreaming this into GCC (making sure it also backports > to 7.3 > >> > for simplicity, so we don't need to write a 7.3-specific patch > for > >> > the > >> > RSB as well) with a few additons (at least for the x86_64 > target, to > >> > try to have an empty bsp_specs to begin with). >
Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs
Hey Joel! I'm not sure if this ever made it upstream - if it did, could you dig the commit up? I'll leave the x86_64's bsp_specs empty and make the RSB backporting patches accordingly. If not, no rush, we should just add a ticket or something so as to not lose track of it entirely after GSoC ends. On Mon, Jul 9, 2018 at 10:30 AM, Amaan Cheval wrote: > To make my previous email clearer, here's what I meant with the > "minimal" GCC patch required (attached). > > To manually test, you can place gcc-STARTFILE_SPEC.patch in > $RSB/rtems/patches/ and then "git apply rsb-startfile.diff" to the RSB > repo. Then build GCC and confirm that "x86_64-rtems5-gcc -dumpspecs" > includes crti and crtbegin in the startfile susbtitution. > > Let me know if we aim to have this GCC work done before merging the > x86_64 BSP (see > https://lists.rtems.org/pipermail/devel/2018-July/022388.html) so I > can leave bsp_specs in or clear it out accordingly? > > For now, I'm going to leave it in. > > On Fri, Jul 6, 2018 at 10:46 AM, Amaan Cheval wrote: >> Hey, Joel! >> >> The x86_64 BSP currently uses an empty bsp_specs file contingent on >> (at least the x86-64 parts of) this email thread's patch making it >> upstream to GCC, and making their way into the RSB. >> >> 2 options: >> - 1. Make the upstream GCC commit (at least the parts adding >> rtemself64.h, editing config.gcc, and "#if 0"ing out >> gcc/config/rtems.h) >> - 2. Use a bsp_specs in the new BSP for the merge now, and empty it out later >> >> I can test and send you an x86_64 specific patch for GCC if you'd >> like. Or if you prefer to have all the work together, we can go with >> #2. >> >> Let me know! >> >> On Sat, May 19, 2018 at 3:17 AM, Joel Sherrill wrote: >>> Thanks. I will try to deal with this Monday. >>> >>> My specs patches are not ready to push to gcc so I need to focus on >>> just the parts to make x86_64 right. >>> >>> On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval >>> wrote: To be clear, I applied this patch (with my fixes) on the 7.3 release through the RSB to test, not on GCC's master branch. > to add i386/rtemself64.h What you sent in this email thread adds rtemself64.h already. Do you mean you'd like to split the commits up or something? The only changes I made on top of yours were: - Readd "rtems.h" to config.gcc - Fix comments I've attached the patch file I used within the RSB here (sorry if you meant a patch of _just_ the fixes I made on top of yours, this is just the cumulative diff I used to patch GCC 7.3 to test). Regards, On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill wrote: > > > > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval > wrote: >> >> I just compiled my local fixed copy (adding rtems.h back in) and >> there's good news! With the patch, the x86_64 compile stub works with >> a blank bsp_specs file! > > > Awesome! > > Can you send me your changes as a patch? I am thinking I need to make > sure we agree on what the gcc master for x86_64-rtems looks like. > > Apparently I owe committing a patch to add i386/rtemself64.h since it is > missing on the master. And the comment is wrong. What else? > >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval >> wrote: >> > Hey! >> > >> > Thanks so much for sharing this, it's quite useful to put your >> > earlier >> > email[1] about minimzing the bsp_specs in context. >> > >> > From looking ahead a bit without testing (still compiling), the patch >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it >> > defines >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely >> > (see here[2]). >> >> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h, >> so there's no need for this change. >> >> > >> > I've also left some comments inline below. >> > >> > +1 on upstreaming this into GCC (making sure it also backports to 7.3 >> > for simplicity, so we don't need to write a 7.3-specific patch for >> > the >> > RSB as well) with a few additons (at least for the x86_64 target, to >> > try to have an empty bsp_specs to begin with). >> > >> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html >> > [2] >> > >> > https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-compile-stub/bsps/x86_64/amd64/start/bsp_specs >> > >> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill >> > wrote: >> >> --- >> >> gcc/config.gcc| 2 +- >> >> gcc/config/arm/rtems.h| 4 >> >> gcc/config/bfin/rtems.h | 4 >> >> gcc/config/i386/rtemself.h| 6 +- >> >>
[PATCH] cpu-supplement: Remove empty command/vars chapter
Close #3498. --- cpu-supplement/command.rst | 8 cpu-supplement/index.rst | 1 - 2 files changed, 9 deletions(-) delete mode 100644 cpu-supplement/command.rst diff --git a/cpu-supplement/command.rst b/cpu-supplement/command.rst deleted file mode 100644 index 45714c9..000 --- a/cpu-supplement/command.rst +++ /dev/null @@ -1,8 +0,0 @@ -.. comment SPDX-License-Identifier: CC-BY-SA-4.0 - -Command and Variable Index -** - -There are currently no Command and Variable Index entries. - -.. COMMENT: @printindex fn diff --git a/cpu-supplement/index.rst b/cpu-supplement/index.rst index 1d810a2..d13992d 100644 --- a/cpu-supplement/index.rst +++ b/cpu-supplement/index.rst @@ -60,7 +60,6 @@ to the Community Project hosted at http://www.rtems.org/. superh sparc sparc64 - command zreferences genindex -- 2.13.7 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] score: Do not inline _Thread_Dispatch_enable()
This function is slighly too complex for inlining with two if
statements. The caller already needs a stack frame due to the potential
call to _Thread_Do_dispatch(). In _Thread_Dispatch_enable() the call to
_Thread_Do_dispatch() can be optimized to a tail call.
A text size comparision
(text size after patch - text size before patch)
/ text size before patch
on sparc/erc32 with SMP enabled showed these results:
Minimum -0.000697892 (fsdosfsname01.exe)
Median -0.00745021 (psxtimes01.exe)
Maximum -0.0233032 (spscheduler01.exe)
A text size comparision
text size after patch - text size before patch
on sparc/erc32 with SMP enabled showed these results:
Minimum -3312 (ada_sp09.exe)
Median -1024 (tm15.exe)
Maximum -592 (spglobalcon01.exe)
---
cpukit/include/rtems/score/threaddispatch.h | 29 ++---
cpukit/score/src/threaddispatch.c | 27 +++
2 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/cpukit/include/rtems/score/threaddispatch.h
b/cpukit/include/rtems/score/threaddispatch.h
index 69696f4044..f5d5c48035 100644
--- a/cpukit/include/rtems/score/threaddispatch.h
+++ b/cpukit/include/rtems/score/threaddispatch.h
@@ -205,36 +205,11 @@ RTEMS_INLINE_ROUTINE Per_CPU_Control
*_Thread_Dispatch_disable( void )
/**
* @brief Enables thread dispatching.
*
- * May perfrom a thread dispatch if necessary as a side-effect.
+ * May perform a thread dispatch if necessary as a side-effect.
*
* @param[in] cpu_self The current processor.
*/
-RTEMS_INLINE_ROUTINE void _Thread_Dispatch_enable( Per_CPU_Control *cpu_self )
-{
- uint32_t disable_level = cpu_self->thread_dispatch_disable_level;
-
- if ( disable_level == 1 ) {
-ISR_Level level;
-
-_ISR_Local_disable( level );
-
-if (
- cpu_self->dispatch_necessary
-#if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
-|| !_ISR_Is_enabled( level )
-#endif
-) {
- _Thread_Do_dispatch( cpu_self, level );
-} else {
- cpu_self->thread_dispatch_disable_level = 0;
- _Profiling_Thread_dispatch_enable( cpu_self, 0 );
- _ISR_Local_enable( level );
-}
- } else {
-_Assert( disable_level > 0 );
-cpu_self->thread_dispatch_disable_level = disable_level - 1;
- }
-}
+void _Thread_Dispatch_enable( Per_CPU_Control *cpu_self );
/**
* @brief Unnests thread dispatching.
diff --git a/cpukit/score/src/threaddispatch.c
b/cpukit/score/src/threaddispatch.c
index 9cd1e294ed..d6207bc898 100644
--- a/cpukit/score/src/threaddispatch.c
+++ b/cpukit/score/src/threaddispatch.c
@@ -267,3 +267,30 @@ void _Thread_Dispatch_direct( Per_CPU_Control *cpu_self )
_ISR_Local_disable( level );
_Thread_Do_dispatch( cpu_self, level );
}
+
+void _Thread_Dispatch_enable( Per_CPU_Control *cpu_self )
+{
+ uint32_t disable_level = cpu_self->thread_dispatch_disable_level;
+
+ if ( disable_level == 1 ) {
+ISR_Level level;
+
+_ISR_Local_disable( level );
+
+if (
+ cpu_self->dispatch_necessary
+#if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
+|| !_ISR_Is_enabled( level )
+#endif
+) {
+ _Thread_Do_dispatch( cpu_self, level );
+} else {
+ cpu_self->thread_dispatch_disable_level = 0;
+ _Profiling_Thread_dispatch_enable( cpu_self, 0 );
+ _ISR_Local_enable( level );
+}
+ } else {
+_Assert( disable_level > 0 );
+cpu_self->thread_dispatch_disable_level = disable_level - 1;
+ }
+}
--
2.13.7
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Tickets: Milestone vs. Version
On 10/08/2018 15:41, Sebastian Huber wrote: > On 10/08/18 07:38, Chris Johns wrote: >> On 10/08/2018 15:03, Sebastian Huber wrote: >>> we want a ticket for each milestone in which it is resolved. What is now the >>> meaning of the version field? >>> >> A ticket may be assigned to a branch but not a milestone. Milestones lets us >> select which tickets we fix on branch. Once all tickets on a milestone are >> closed the release can be made. >> >> We do not work that way at the moment. I use the milestones when making >> releases >> to move tickets scheduled for a release that are not closed to the next >> release. > > This doesn't explain the version field. Is version the same as branch from > your > point of view? > The branch is the version of RTEMS released from that branch. In trac it is called version, ie 4.11, 4.10, 5 etc. The term version is more accurate, the use of branch is actually a VC implementation detail. I think https://devel.rtems.org/wiki/Developer/Release could do with some work. May be the following from https://devel.rtems.org/wiki/Developer/Release#ReleaseTerminology should be ... Release Terminology - A release is the creation of any generated files and their packaging together with the source in a repository that makes the package available as a file. - A release branch is a git branch pushed to the repositories used to create release. There is a release branch for each version of RTEMS. - A release is a git tag on a release branch with the tags pushed to the repositories. ? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
