RTEMS / Programs / Google Summer of Code¶
Go to Issues or rtems/programs/gsoc-merges
Merge Requests Summary
Issues¶
76 - dtc build failure on msys2 - all rtems6 target tools fail to build on Windows 10¶
Id |
76 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Closed by |
Amar Takhar |
Created |
2021-11-11T21:08:30.000Z |
Closed |
2024-10-03T02:38:53.002Z |
Updated |
2024-10-03T02:38:53.175Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::small, priority::normal, tickettype::defect, tool::rtems-source-builder |
Link |
|
Merges |
0 |
Original author: kgardas
I’m testing RSB git source updated 2021-11-10 and it fails on freshly installed msys2/windows 10 platform with:
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems
$ ../source-builder/sb-check
RTEMS Source Builder - Check, 6 (efa44e47a7d2 modified)
Environment is ok
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems
$ ../source-builder/sb-set-builder --prefix=/c/r/rr 6/rtems-sparc
RTEMS Source Builder - Set Builder, 6 (efa44e47a7d2 modified)
Build Set: 6/rtems-sparc
config: devel/dtc-1.6.0-1.cfg
package: dtc-1.6.0-x86_64-w64-mingw32-1
building: dtc-1.6.0-x86_64-w64-mingw32-1
error: building d1xwm1
Build FAILED
See error report: rsb-report-dtc-1.6.0-x86_64-w64-mingw32-1.txt
error: building d1xwm1
Build Set: Time 0:00:28.232196
Build FAILED
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems
$
the problem report is attached.
Joel adds: dtc does not build on msys2. It requires fnmatch.h which is not present. Alternative fixes include finding an alternative for fnmatch on msys2, providing an implementation to be used on msys2, or adding gnulib which is a portability package to our RSB packages on msys2.
Also there may be other tickets for the same issue.
Possible Mentors: Karel Gardas Skills: C Difficulty: Medium
Author: Amar Takhar
2024-04-26T01:34:53.550Z
assigned to @tracmigrate
Author: Trac Migrate
2021-11-11T21:09:20.000Z
Original author: kgardas
Attachment rsb-report-dtc-1.6.0-x86_64-w64-mingw32-1.txt added
dtc compilation failure problem report.
Author: Joel Sherrill
2022-02-02T14:23:22.000Z
Original author: kgardas
Milestone set to rtems%”6.1”
Adding SoC as a ticket because I think this is a possible small SoC project. Possible solutions include adding gnulib to the RSB bset for msys2 or modifying dtc to use other APIs for this functionality.
Author: Joel Sherrill
2022-02-04T20:05:29.000Z
Original author: kgardas
Description changed
I'm testing RSB git source updated 2021-11-10 and it fails on freshly installed msys2/windows 10 platform with:karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $ ../source-builder/sb-check RTEMS Source Builder - Check, 6 (efa44e47a7d2 modified) Environment is ok
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $ ../source-builder/sb-set-builder –prefix=/c/r/rr 6/rtems-sparc RTEMS Source Builder - Set Builder, 6 (efa44e47a7d2 modified) Build Set: 6/rtems-sparc config: devel/dtc-1.6.0-1.cfg package: dtc-1.6.0-x86_64-w64-mingw32-1 building: dtc-1.6.0-x86_64-w64-mingw32-1 error: building d1xwm1 Build FAILED See error report: rsb-report-dtc-1.6.0-x86_64-w64-mingw32-1.txt error: building d1xwm1 Build Set: Time 0:00:28.232196 Build FAILED
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $
the problem report is attached. + + Joel adds: dtc does not build on msys2. It requires fnmatch.h which is not present. Alternative fixes include finding an alternative for fnmatch on msys2, providing an implementation to be used on msys2, or adding gnulib which is a portability package to our RSB packages on msys2. + + Also there may be other tickets for the same issue.
Summary changed from RSB can’t build rtems-sparc target tools on Windows 10. to dtc build failure on msys2 - all rtems6 target tools fail to build on Windows 10
Author: Joel Sherrill
2022-02-25T21:15:50.000Z
Original author: kgardas
Description changed
I'm testing RSB git source updated 2021-11-10 and it fails on freshly installed msys2/windows 10 platform with:karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $ ../source-builder/sb-check RTEMS Source Builder - Check, 6 (efa44e47a7d2 modified) Environment is ok
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $ ../source-builder/sb-set-builder –prefix=/c/r/rr 6/rtems-sparc RTEMS Source Builder - Set Builder, 6 (efa44e47a7d2 modified) Build Set: 6/rtems-sparc config: devel/dtc-1.6.0-1.cfg package: dtc-1.6.0-x86_64-w64-mingw32-1 building: dtc-1.6.0-x86_64-w64-mingw32-1 error: building d1xwm1 Build FAILED See error report: rsb-report-dtc-1.6.0-x86_64-w64-mingw32-1.txt error: building d1xwm1 Build Set: Time 0:00:28.232196 Build FAILED
karel@DESKTOP-755H9VE MINGW64 /c/r/rtems-source-builder/rtems $
the problem report is attached. Joel adds: dtc does not build on msys2. It requires fnmatch.h which is not present. Alternative fixes include finding an alternative for fnmatch on msys2, providing an implementation to be used on msys2, or adding gnulib which is a portability package to our RSB packages on msys2. Also there may be other tickets for the same issue. + + Possible Mentors: Karel Gardas + Skills: C + Difficulty: Medium
Author: Chris Johns
2022-11-29T23:48:28.000Z
Original author: kgardas
status update?
Author: Gedare Bloom
2024-02-17T05:15:05.000Z
Original author: kgardas
Owner set to kgardas
Status changed from new to assigned
Author: Amar Takhar
2024-04-25T20:49:19.387Z
changed the description
Author: Amar Takhar
2024-10-03T02:38:53.241Z
moved to rtems/tools/rtems-source-builder#36
72 - Use thread-local storage for Newlib reentrancy objects¶
Id |
72 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Trac Migrate |
Created |
2021-12-03T09:04:00.000Z |
Updated |
2024-04-26T01:34:51.859Z |
Milestone |
6.1 |
Labels |
gsoc, gsoc::large, priority::normal, qualification, resolution::fixed, tickettype::project, tool::newlib, version::7 |
Link |
|
Merges |
0 |
Original author: sebastian.huber
Problem¶
The state of the art architectures supported by RTEMS have all efficient support for thread-local storage (MIPS has issues with thread-local storage, however, is MIPS state of the art?).
Newlib currently uses a huge object of type struct _reent to store thread-specific data. This object is returned by __getreent(). It is related to the __DYNAMIC_REENT__ Newlib configuration option which is always defined for RTEMS.
The reentrancy structure contains errno and also the standard input, output, and error file streams. This means that if an application only uses errno it has a dependency on the file stream support event if it does not use it. This is an issue for lower end targets and the pre-qualification of RTEMS.
Solution¶
One approach to disentangle the dependencies introduced by struct _reent is to get rid of this structure and replace the individual members of the structure with thread-local objects. For example, instead of
struct _reent {
int _errno;
__FILE *_stdin;
__FILE *_stdout;
__FILE *_stderr;
};
use
_Thread_local int _errno;
_Thread_local __FILE *_stdin;
_Thread_local __FILE *_stdout;
_Thread_local __FILE *_stderr;
Newlib already has access macros for the struct _reent members, for example:
#define _REENT_SIGNGAM(ptr) ((ptr)->_new._reent._gamma_signgam)
#define _REENT_RAND_NEXT(ptr) ((ptr)->_new._reent._rand_next)
#define _REENT_RAND48_SEED(ptr) ((ptr)->_new._reent._r48._seed)
#define _REENT_RAND48_MULT(ptr) ((ptr)->_new._reent._r48._mult)
#define _REENT_RAND48_ADD(ptr) ((ptr)->_new._reent._r48._add)
How-to Implement¶
The member access macros are incomplete. The first step is to use the Newlib configuration for RTEMS as is and rename all struct _reent members, for example add an TEMPORARY prefix to all member names, _errno to TEMPORARY_errno. Then add member access macros until Newlib builds again. Install this Newlib and check that RTEMS and libbsd compiles. Run the RTEMS and libbsd test suites to check for regressions.
In a second step to this for the _REENT_SMALL configuration of Newlib.
The third step is to add a new Newlib configuration option, for example _REENT_THREAD_LOCAL which turns the struct _reent members into thread-local objects with corresponding “member” access macros. Define _REENT to NULL.
Skills¶
C and assembly
Difficulty¶
This is a large (350-hour) project of hard difficulty.
Author: Amar Takhar
2024-04-26T01:34:51.829Z
assigned to @tracmigrate
Author: Joel Sherrill
2021-12-03T17:29:59.000Z
Original author: sebastian.huber
One issue with this is that TLS is not supported on all architectures. We would either have to have two methods (current and TLS) to do this or fix TLS everywhere.
Author: Trac Migrate
2021-12-03T19:20:33.000Z
Original author: sebastian.huber
I am not sure what the Newlib maintainer say if we try to add a third reentrancy approach. I guess for backward compatibility they want to keep the existing methods anyway.
Author: Chris Johns
2021-12-06T08:19:37.000Z
Original author: sebastian.huber
I would like to see
libdlsupport for TLS added to RTEMS.
Author: Trac Migrate
2022-01-28T07:35:58.000Z
Original author: sebastian.huber
In [changeset:”b519e509a953c25894700531c321f7213fa11e70/rtems” b519e50/rtems]:
sptests: Avoid a dependency on errno Avoid a dependency on errno which might be a thread-local object. The tests sp01, spstkalloc02, and sptls03 assume that no thread-local storage object is present. Update #4560.
Author: Trac Migrate
2022-01-28T07:38:25.000Z
Original author: sebastian.huber
Related discussion on libc-coord:
Author: Gedare Bloom
2022-02-25T18:27:59.000Z
Original author: sebastian.huber
Description changed
= Problem The state of the art architectures supported by RTEMS have all efficient support for thread-local storage (MIPS has issues with thread-local storage, however, is MIPS state of the art?). Newlib currently uses a huge object of type `struct _reent` to store thread-specific data. This object is returned by `__getreent()`. It is related to the `__DYNAMIC_REENT__` Newlib configuration option which is always defined for RTEMS. The reentrancy structure contains `errno` and also the standard input, output, and error file streams. This means that if an application only uses `errno` it has a dependency on the file stream support event if it does not use it. This is an issue for lower end targets and the pre-qualification of RTEMS. = Solution One approach to disentangle the dependencies introduced by `struct _reent` is to get rid of this structure and replace the individual members of the structure with thread-local objects. For example, instead of {{{#!c struct _reent { int _errno; __FILE *_stdin; __FILE *_stdout; __FILE *_stderr; }; }}} use {{{#!c _Thread_local int _errno; _Thread_local __FILE *_stdin; _Thread_local __FILE *_stdout; _Thread_local __FILE *_stderr; }}} Newlib already has access macros for the `struct _reent` members, for example: {{{#!c #define _REENT_SIGNGAM(ptr) ((ptr)->_new._reent._gamma_signgam) #define _REENT_RAND_NEXT(ptr) ((ptr)->_new._reent._rand_next) #define _REENT_RAND48_SEED(ptr) ((ptr)->_new._reent._r48._seed) #define _REENT_RAND48_MULT(ptr) ((ptr)->_new._reent._r48._mult) #define _REENT_RAND48_ADD(ptr) ((ptr)->_new._reent._r48._add) }}} = How-to Implement The member access macros are incomplete. The first step is to use the Newlib configuration for RTEMS as is and rename all `struct _reent` members, for example add an `TEMPORARY` prefix to all member names, `_errno` to `TEMPORARY_errno`. Then add member access macros until Newlib builds again. Install this Newlib and check that RTEMS and libbsd compiles. Run the RTEMS and libbsd test suites to check for regressions. In a second step to this for the `_REENT_SMALL` configuration of Newlib. The third step is to add a new Newlib configuration option, for example `_REENT_THREAD_LOCAL` which turns the `struct _reent` members into thread-local objects with corresponding "member" access macros. Define `_REENT` to `NULL`. + + = Skills = + C and assembly + + = Difficulty = + This is a large (350-hour) project of hard difficulty.
Author: Trac Migrate
2022-06-29T09:04:57.000Z
Original author: sebastian.huber
Milestone changed from rtems%”7.1” to rtems%”6.1”
Version changed from ~”7” to ~”6”
Author: Trac Migrate
2022-07-21T05:15:04.000Z
Original author: sebastian.huber
In [changeset:”57a569efe16c2b8e9579147fdd78ee909c7558d3/rtems” 57a569e/rtems]:
sptests: Disable Newlib reentrancy Update #4560.
Author: Trac Migrate
2022-07-21T05:15:06.000Z
Original author: sebastian.huber
In [changeset:”6d4b390f99af0e9d5873a3cb8ebaccfa05cbe37b/rtems” 6d4b390/rtems]:
Support _REENT_THREAD_LOCAL Newlib configuration In case the Newlib _REENT_THREAD_LOCAL configuration option is enabled, the struct _reent is not defined (there is only a forward declaration in <sys/reent.h>). Instead, the usual members of struct _reent are available as dedicatd thread-local storage objects. Update #4560.
Author: Trac Migrate
2022-07-21T08:25:04.000Z
Original author: sebastian.huber
In [changeset:”ae6e5983d801cc8c44bc9aa0c6ab85b7d23ac1e8/rtems-source-builder” ae6e598/rtems-source-builder]:
6/7: Update Newlib This makes the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option available. Update #4560.
Author: Trac Migrate
2022-07-21T08:25:05.000Z
Original author: sebastian.huber
In [changeset:”958de508aa141deb4c8a115560aeec80dbdad3e8/rtems-source-builder” 958de50/rtems-source-builder]:
newlib: Support --with/without-newlib-tls This RSB option defines if the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option is used or not. Update #4560.
Author: Trac Migrate
2022-07-21T08:25:06.000Z
Original author: sebastian.huber
In [changeset:”f4f5d43a98051f7562103aaa2ec7723c628c6947/rtems-source-builder” f4f5d43/rtems-source-builder]:
6/7: Use TLS in Newlib for some targets by default Use the --enable-newlib-reent-thread-local (_REENT_THREAD_LOCAL_STORAGE) Newlib configuration option on the aarch64, arm, nios2, powerpc, riscv, and sparc targets by default. Update #4560.
Author: Trac Migrate
2022-08-08T11:00:15.000Z
Original author: sebastian.huber
Attachment gcc-10-RTEMS-Use-local-exec-TLS-model-by-default.patch added
Author: Trac Migrate
2022-08-08T11:00:32.000Z
Original author: sebastian.huber
Attachment gcc-12-RTEMS-Use-local-exec-TLS-model-by-default.patch added
Author: Trac Migrate
2022-08-08T18:23:20.000Z
Original author: sebastian.huber
In [changeset:”eea379370116628dbe91f19e61ad6129aa1951ac/rtems-source-builder” eea3793/rtems-source-builder]:
6: Use local-exec TLS model by default Update #4560.
Author: Trac Migrate
2022-09-09T05:32:55.000Z
Original author: sebastian.huber
In [changeset:”91e8654b1151db78b19ddcfe0ad10e386a8f2fe3/rtems-docs” 91e8654/rtems-docs]:
user: Document RSB --with/without-newlib-tls Update #4560.
Author: Trac Migrate
2022-10-14T09:41:39.000Z
Original author: sebastian.huber
In [changeset:”b9212e242fd2cb4b7821eea942d414cc84c27006/rtems” b9212e2/rtems]:
sptls01: Disable file system and Newlib reentrancy Update #4560.
Author: Chris Johns
2022-11-29T22:38:23.000Z
Original author: sebastian.huber
Are we able to close this ticket?
Author: Trac Migrate
2022-11-30T08:59:07.000Z
Original author: sebastian.huber
Resolution set to ~”fixed”
Status changed from assigned to closed
Yes, I recently were able to integrate the final patch for GCC 13. A follow up activity is rtems/rtos/rtems#4765.
Author: Trac Migrate
2023-04-26T05:14:33.000Z
Original author: sebastian.huber
In [changeset:”908efe4393f158e6e83a1a9ecc84b469f43201fa/rtems-source-builder” 908efe4/rtems-source-builder]:
7: Use TLS in Newlib for m68k by default Update #4560.
Author: Amar Takhar
2024-04-25T20:49:22.256Z
changed the description
23 - Port RTEMS to Microblaze¶
Id |
23 |
State |
closed |
Type |
ISSUE |
Author |
Trac Migrate |
Assignee(s) |
Joel Sherrill |
Created |
2017-02-06T02:59:16.000Z |
Updated |
2024-04-26T01:34:29.883Z |
Milestone |
6.1 |
Labels |
bsp, gsoc, priority::normal, resolution::fixed, tickettype::project, version::4.11 |
Link |
|
Merges |
0 |
Original author: tokencolour
Port RTEMS to Microblaze¶
Students: Past, Present, and Potential Students
Status: The tools build from RSB properly, but GDB is not compatible with current XDM (Xilinx Debugging Module), Xilinx GDB version is working fine.
Introduction: A new architecture port, not just BSP. Include a BSP for GDB simulator. Also needs BSP for more complete HW on simulator.
Goal: Update the preliminary Microblaze port, complete clock timer support, merge into RTEMS, and continue to improve the BSP/port.
Some work has been initiated here [1] (By Joel Sherrill and Hesham ALMatary) to get hello world working. It has been tested on Atlys FPGA board [2]. The BSP can run virtually on every FPGA board the Xilinx tools support building MicroBlaze on.
The work will need to be updated against the current RTEMS version and tools and then completed. There are multiple boards supported by qemu-system-microblaze. One of these should be suitable for completing the port including interrupts. It will require investigation to know if qemu includes networking support for the Microblaze but this is likely.
References¶
[2] www.digilentinc.com/atlys/
Author: Amar Takhar
2024-04-26T01:34:29.856Z
assigned to @joel
Author: Chris Johns
2017-08-14T00:04:23.000Z
Original author: tokencolour
Version ~”4.11” deleted
Author: Gedare Bloom
2020-01-14T20:53:20.000Z
Original author: tokencolour
Description changed
= Port RTEMS to Microblaze = **Students:** Past, Present, and Potential Students **Status:** The tools build from RSB properly, but GDB is not compatible with current XDM (Xilinx Debugging Module), Xilinx GDB version is working fine. **Introduction:** A new architecture port, not just BSP. Include a BSP for GDB simulator. Also needs BSP for more complete HW on simulator. - **Goal:** Concise statement of the overall goal of the project. Refine this initial statement to include: project deliverables (code, docs, testing), required/suggested methodology, standards of quality, possible goal extensions beyond the main objective. + **Goal:** Update the preliminary Microblaze port, complete clock timer support, merge into RTEMS, and continue to improve the BSP/port. - **Requirements:** List the requirements and level of expertise you estimate are required by the developer tackling this project will have to have: Required level of programming language(s), specific areas of RTEMS or tools, level of familiarity with RTEMS, cross-development, GNU/Linux, etx., development/documentation/testing tools, mathematical/algorithmic background, other desirable skills. - - **Resources:** Current RTEMS developers, papers, etc that may help you in this project. - - **Acknowledgements** - * who helped and did work * Some work has been initiated here [1] (By Joel Sherrill and Hesham ALMatary) to get hello world working. It has been tested on Atlys FPGA board [2]. The BSP can run virtually on every FPGA board the Xilinx tools support building MicroBlaze on. - - = Miscellaneous Sections = - - As the project progresses, you will need to add build instructions, etc and this page will evolve from a project description into a HOWTO. = References = * [1] https://github.com/heshamelmatary/rtems-microblaze * [2] www.digilentinc.com/atlys/ - **Other sections:** If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will.
Author: Joel Sherrill
2020-05-29T12:58:33.000Z
Original author: tokencolour
Description changed
= Port RTEMS to Microblaze = **Students:** Past, Present, and Potential Students **Status:** The tools build from RSB properly, but GDB is not compatible with current XDM (Xilinx Debugging Module), Xilinx GDB version is working fine. **Introduction:** A new architecture port, not just BSP. Include a BSP for GDB simulator. Also needs BSP for more complete HW on simulator. **Goal:** Update the preliminary Microblaze port, complete clock timer support, merge into RTEMS, and continue to improve the BSP/port. - * Some work has been initiated here [1] (By Joel Sherrill and Hesham ALMatary) to get hello world working. It has been tested on Atlys FPGA board [2]. The BSP can run virtually on every FPGA board the Xilinx tools support building MicroBlaze on. ? ---- - + Some work has been initiated here [1] (By Joel Sherrill and Hesham ALMatary) to get hello world working. It has been tested on Atlys FPGA board [2]. The BSP can run virtually on every FPGA board the Xilinx tools support building MicroBlaze on. + + The work will need to be updated against the current RTEMS version and tools and then completed. There are multiple boards supported by qemu-system-microblaze. One of these should be suitable for completing the port including interrupts. It will require investigation to know if qemu includes networking support for the Microblaze but this is likely. = References = * [1] https://github.com/heshamelmatary/rtems-microblaze * [2] www.digilentinc.com/atlys/
Author: Joel Sherrill
2021-11-11T17:54:41.000Z
Original author: tokencolour
Milestone changed from rtems%”Indefinite” to rtems%”6.1”
Resolution set to ~”fixed”
Status changed from new to closed
A Microblaze port and BSP for the KCU105 (HW and Qemu) have been merged. LWIP and libbsd should be supported soon. Closing.
Author: Amar Takhar
2024-04-25T20:45:21.645Z
changed the description