Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

On Fri, Sep 11, 2020 at 5:31 PM Chris Johns wrote: > > On 12/9/20 12:10 am, Joel Sherrill wrote: > > This thread has wandered a lot but I just wanted to say > > I am OK with the direction this is going. I think we have > > made this about as safe and easy to use as possible. > > Yes. > > > Did

Re: pc386 BSP/master branch build failure with smp enabled.

On Fri, Sep 11, 2020 at 11:53 AM Karel Gardas wrote: > > On 9/11/20 6:16 PM, Gedare Bloom wrote: > > Looks to be coming through > > > > cpukit/score/cpu/i386/include/rtems/asm.h:157 movb > > imps_apic_cpu_map(\REG),\REG/* CPU ID in REG */ > > > > The assembler is right to complain. movb

rtems_task_create_from_config() Name?

Hi Starting another thread just to discuss this method's name. I wonder if the config part is more important than the static allocation of resources part. Which should be emphasized in the name? >From config puts focus on the attributes part. With static resources or similar puts emphasis on the

Re: x86 c++ exception handling

On Fri, Sep 11, 2020, 7:29 PM Chris Johns wrote: > On 12/9/20 12:41 am, Joel Sherrill wrote: > > On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas > > wrote: > > > > On 9/11/20 3:13 PM, Joel Sherrill wrote: > > > FWIW i386 is an 80s CPU introduced in 1985.

Re: [PATCH v4 2/5] rtems: Add rtems_task_create_from_config()

On 12/9/20 1:34 am, Sebastian Huber wrote: > + * @par Notes > + * By default, the calculation for the required memory in the RTEMS Workspace > + * for tasks assumes that all Classic API Tasks are created by > + * rtems_task_create(). This configuration option can be used to reduce the > + *

Re: [PATCH v4 1/5] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

On 12/9/20 1:34 am, Sebastian Huber wrote: > +const size_t _Thread_Maximum_TLS_size = > + CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE; Should rtems-exeinfo report this? Chris ___ devel mailing list devel@rtems.org

Re: x86 c++ exception handling

On 12/9/20 12:41 am, Joel Sherrill wrote: > On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas > wrote: > > On 9/11/20 3:13 PM, Joel Sherrill wrote: > > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced > > in 1989. The Pentium was 1993.

Re: BSP Test Results

On 9/9/20 6:49 pm, Sebastian Huber wrote: > On 09/09/2020 02:29, Chris Johns wrote: >>> This would be enough to address my "HW or which simulator" question. >> I had created #4072, please update adding the items you would like. We can >> add >> anything you like and they can be mandated. There

Re: BSP Test Results

On 9/9/20 6:47 pm, Sebastian Huber wrote: > On 09/09/2020 02:36, Chris Johns wrote: >> On 9/9/20 3:13 am, Gedare Bloom wrote: >>> On Sun, Sep 6, 2020 at 8:55 PM Chris Johns  wrote: An example using Joel's recent test run (thanks Joel :)). The sparc/leon2 results show no regressions:

Re: New Build System Status

On 12/9/20 5:35 am, Joel Sherrill wrote: > On Fri, Sep 11, 2020 at 2:00 PM Gedare Bloom > wrote: > > On Fri, Sep 11, 2020 at 12:03 PM Sebastian Huber > > wrote: > > > > On 11/09/2020 17:46, Gedare Bloom

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

On 12/9/20 12:10 am, Joel Sherrill wrote: > This thread has wandered a lot but I just wanted to say  > I am OK with the direction this is going.  I think we have > made this about as safe and easy to use as possible. Yes. > Did we decide if there had to be an explicit configure  > option to even

Re: [PATCH] Confstr Patches

This looks close to me but I see some minor issues. I have tried to annotate them. The spacing ones could be spaces vs tabs. Not sure. On Thu, Sep 10, 2020 at 3:48 PM Eshan dhawan wrote: > Adds Confstr file To RTEMS with test > > Signed-off-by: Eshan dhawan > --- > cpukit/Makefile.am

Re: New Build System Status

On Fri, Sep 11, 2020 at 2:00 PM Gedare Bloom wrote: > On Fri, Sep 11, 2020 at 12:03 PM Sebastian Huber > wrote: > > > > On 11/09/2020 17:46, Gedare Bloom wrote: > > > > > I have nothing pending. I think we should switch early next week, sort > > > out any bugs during the week? > > This sounds

Re: New Build System Status

On Fri, Sep 11, 2020 at 12:03 PM Sebastian Huber wrote: > > On 11/09/2020 17:46, Gedare Bloom wrote: > > > I have nothing pending. I think we should switch early next week, sort > > out any bugs during the week? > This sounds good. I can do some final tests builds over the week end and > then

Re: New coding style for new files?

On Fri, Sep 11, 2020 at 1:11 PM Peter Dufault wrote: > > > > On Sep 11, 2020, at 13:43 , Joel Sherrill wrote: > > > > https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify > > > > I've been using "uncrustify" for a long time. There are regular updates > and quick responses for

Re: New coding style for new files?

> On Sep 11, 2020, at 13:43 , Joel Sherrill wrote: > > https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify > I've been using "uncrustify" for a long time. There are regular updates and quick responses for clearly reported issues. The formatting specification is complicated,

Re: New Build System Status

On 11/09/2020 17:46, Gedare Bloom wrote: I have nothing pending. I think we should switch early next week, sort out any bugs during the week? This sounds good. I can do some final tests builds over the week end and then push it on Monday morning.

Re: pc386 BSP/master branch build failure with smp enabled.

On 9/11/20 6:16 PM, Gedare Bloom wrote: > Looks to be coming through > > cpukit/score/cpu/i386/include/rtems/asm.h:157 movb > imps_apic_cpu_map(\REG),\REG/* CPU ID in REG */ > > The assembler is right to complain. movb has to target one of the > 1-byte mnemonics, so this should be %al

Re: New coding style for new files?

https://ftp.rtems.org/pub/rtems/people/amar/files/rtems.uncrustify On Fri, Sep 11, 2020 at 11:46 AM Joel Sherrill wrote: > > > On Fri, Sep 11, 2020 at 11:06 AM Gedare Bloom wrote: > >> On Fri, Sep 11, 2020 at 1:41 AM Sebastian Huber >> wrote: >> > >> > On 10/09/2020 17:32, Joel Sherrill

Re: New coding style for new files?

On Fri, Sep 11, 2020 at 11:06 AM Gedare Bloom wrote: > On Fri, Sep 11, 2020 at 1:41 AM Sebastian Huber > wrote: > > > > On 10/09/2020 17:32, Joel Sherrill wrote: > > > > > > > > > > > On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom > > > wrote: > > > > > > On Mon,

Re: pc386 BSP/master branch build failure with smp enabled.

Looks to be coming through cpukit/score/cpu/i386/include/rtems/asm.h:157 movb imps_apic_cpu_map(\REG),\REG/* CPU ID in REG */ The assembler is right to complain. movb has to target one of the 1-byte mnemonics, so this should be %al for the LSB of %eax. One needs to check through this

Re: New coding style for new files?

On Fri, Sep 11, 2020 at 1:41 AM Sebastian Huber wrote: > > On 10/09/2020 17:32, Joel Sherrill wrote: > > > > > > > On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom > > wrote: > > > > On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber > > >

Re: New Build System Status

I have nothing pending. I think we should switch early next week, sort out any bugs during the week? On Fri, Sep 11, 2020 at 4:52 AM Christian Mauderer wrote: > > On 11/09/2020 09:19, Chris Johns wrote: > > On 11/9/20 5:14 pm, Sebastian Huber wrote: > >> are there any remaining issues which

[PATCH v4 0/5] rtems: Add rtems_task_create_from_config()

v2: Rename function from rtems_task_build() to rtems_task_create_from_config(). Add RTEMS_TASK_STORAGE_ALIGNMENT and RTEMS_TASK_STORAGE_SIZE(). Improve documentation. v3: Add CONFIGURE_TASKS_CREATED_FROM_CONFIG. Fix RTEMS_TASK_STORAGE_SIZE() if CPU_ALL_TASKS_ARE_FP == TRUE. v4: Add

[PATCH v4 5/5] validation: rtems_task_create_from_config() errors

This is the first test case generated from a specification item in the rtems-central repository. Update #3959. --- .../tc-tasks-create-from-config-errors.c | 2369 + 1 file changed, 2369 insertions(+) create mode 100644

[PATCH v4 2/5] rtems: Add rtems_task_create_from_config()

In contrast to rtems_task_create() this function creates a task with a user-provided task storage area. The new create function uses a configuration structure instead of individual parameters. Add RTEMS_TASK_STORAGE_ALIGNMENT to define the recommended alignment of a task storage area. Add

[PATCH v4 4/5] validation: Add general purpose test suite

Add a general purpose test suite for validation tests. This is the first test suite generated from a specification item in the rtems-central repository. Update #3959. --- Doxyfile| 2 +- cpukit/doxygen/top-level-groups.h | 6 +

[PATCH v4 1/5] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

Add this application configuration option. This configuration option can be used to reserve space for the dynamic linking of modules with thread-local storage objects. Update #4074. --- cpukit/doxygen/appl-config.h| 29 +++ cpukit/include/rtems/confdefs/threads.h |

[PATCH v4 3/5] doxygen: Move top-level group definitions

Update #3959. --- cpukit/doxygen.h | 18 - cpukit/doxygen/top-level-groups.h | 44 +++ 2 files changed, 44 insertions(+), 18 deletions(-) create mode 100644 cpukit/doxygen/top-level-groups.h diff --git a/cpukit/doxygen.h

Re: x86 c++ exception handling

On Fri, Sep 11, 2020 at 9:06 AM Karel Gardas wrote: > On 9/11/20 3:13 PM, Joel Sherrill wrote: > > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced > > in 1989. The Pentium was 1993. Remember It's All About the Pentium! > > Pentium II was 1997 and first with SMP but maybe not

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

This thread has wandered a lot but I just wanted to say I am OK with the direction this is going. I think we have made this about as safe and easy to use as possible. Did we decide if there had to be an explicit configure option to even use this API? Chris and I discussed this as an idea to

Re: x86 c++ exception handling

On 9/11/20 4:06 PM, Karel Gardas wrote: > One exception found is Vertex86 cpus which still sells and boards are Typo correction: Vortex86: https://en.wikipedia.org/wiki/Vortex86 ___ devel mailing list devel@rtems.org

Re: x86 c++ exception handling

On 9/11/20 3:13 PM, Joel Sherrill wrote: > FWIW i386 is an 80s CPU introduced in 1985. i486 was introduced > in 1989. The Pentium was 1993. Remember It's All About the Pentium! > Pentium II was 1997 and first with SMP but maybe not setting the baseline > we want. What about to support in master

Re: x86 c++ exception handling

On Fri, Sep 11, 2020 at 5:12 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 11/09/2020 12:08, Karel Gardas wrote: > > > On 9/11/20 11:40 AM, Sebastian Huber wrote: > > > >>> If I'm not mistaken, then this is simply fixed by using other BSP's > >>> variant? Like

pc386 BSP/master branch build failure with smp enabled.

Hello, I've built 6/rtems-i386 tools using master branch of rtems-source-builder. $ i386-rtems6-gcc -v Using built-in specs. COLLECT_GCC=i386-rtems6-gcc COLLECT_LTO_WRAPPER=/export/home/karel/sfw/rtems/6-head-2020-09-11/libexec/gcc/i386-rtems6/10.2.1/lto-wrapper Target: i386-rtems6 Configured

Re: New Build System Status

On 11/09/2020 09:19, Chris Johns wrote: > On 11/9/20 5:14 pm, Sebastian Huber wrote: >> are there any remaining issues which prevent the new build system from being >> integrated? At the moment I just sit idle and wait. If there are technical >> issues, I can fix them only if I know them. > > I

Re: x86 c++ exception handling

On 11/09/2020 12:08, Karel Gardas wrote: On 9/11/20 11:40 AM, Sebastian Huber wrote: If I'm not mistaken, then this is simply fixed by using other BSP's variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs and gcc's lib provides necessary synchronization functions then...

Re: x86 c++ exception handling

On 9/11/20 11:40 AM, Sebastian Huber wrote: >> If I'm not mistaken, then this is simply fixed by using other BSP's >> variant? Like pc486/pc586/pc686 ... Those optimize for different CPUs >> and gcc's lib provides necessary synchronization functions then... > The question is if there are RTEMS

Re: x86 c++ exception handling

On 11/09/2020 11:21, Karel Gardas wrote: There is also an associated ticket: http://devel.rtems.org/ticket/2830 I think the i386 BSPs need to be cleaned up to use an instruction set which fits current the x86 hardware. I mean hardware which is still in use and not some stuff from the 1990s.

Re: x86 c++ exception handling

On 9/11/20 11:12 AM, Sebastian Huber wrote: > On 11/09/2020 10:48, Heinz Junkes wrote: > >> Here is a mail I received from a colleague. >> >> It concerns thereby an "old" problem which seemed already solved? >> >> FYI. I can run the unit tests, but I'm seeing a couple of hangs. >> The first I'm

Re: x86 c++ exception handling

On 11/09/2020 10:48, Heinz Junkes wrote: Here is a mail I received from a colleague. It concerns thereby an "old" problem which seemed already solved? FYI. I can run the unit tests, but I'm seeing a couple of hangs. The first I'm looking at is epicsTimeTest which seems to be related to c++

x86 c++ exception handling

Here is a mail I received from a colleague. It concerns thereby an "old" problem which seemed already solved? FYI. I can run the unit tests, but I'm seeing a couple of hangs. The first I'm looking at is epicsTimeTest which seems to be related to c++ exception handling. I recall that there were

Re: New coding style for new files?

On 10/09/2020 17:32, Joel Sherrill wrote: On Thu, Sep 10, 2020 at 10:24 AM Gedare Bloom > wrote: On Mon, Sep 7, 2020 at 12:06 AM Sebastian Huber mailto:sebastian.hu...@embedded-brains.de>> wrote: > > Hello, > > I think we waste too much time

Re: New Build System Status

On 11/9/20 5:14 pm, Sebastian Huber wrote: > are there any remaining issues which prevent the new build system from being > integrated? At the moment I just sit idle and wait. If there are technical > issues, I can fix them only if I know them. I have none. > I have a BSP using the new build

Re: New Build System Status

Hello, On 16/07/2020 17:16, Sebastian Huber wrote: Hello, I sent the documentation of the new build system some days ago and at least Gedare Bloom reviewed it. https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf I rebased the build

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

On 11/9/20 5:07 pm, Sebastian Huber wrote: > On 11/09/2020 09:00, Chris Johns wrote: > >> Considering this some more I wonder if the TCB >> should have a flag set to say the allocator was "static". This could be >> reported >> by the `task` command and may be even via an API call. Users could

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

On 11/09/2020 09:00, Chris Johns wrote: Considering this some more I wonder if the TCB should have a flag set to say the allocator was "static". This could be reported by the `task` command and may be even via an API call. Users could then inspect and check their system. We don't need a flag

Re: [PATCH] CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE

On 11/9/20 12:40 am, Joel Sherrill wrote: > How is the user/system integrator supposed to figure out the size of the TLS? > It > is not known until the application is linked and thus varies based on the > total > set of code linked. Yes the user links the application and inspects the

Virus Warning

Hello, I assume that most of you are careful anyway. But nonetheless a virus warning: I received a message that pretends to be an answer to a RTEMS mailing list post. The mail has a .doc file attached that contains a virus. Text of the mail is: -- Good afternoon! It is regarding