RTEMS / RTOS / RTEMS

Go to Issues or Merge Requests

Merge Requests Summary


Issues

4564 - close_editor problem of RTEMS4.13/5.1

Id

4564

State

closed

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Trac Migrate

Created

2021-12-05T14:03:15.000Z

Updated

2025-09-19T01:22:45.313Z

Milestone

5.3

Labels

cpukit::shell, priority::normal, resolution::fixed, rtems::shell, tickettype::defect, version::5

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4564

Merges

1

Original author: chenjin_zhong

Hi, I find when close editor in shell console.some errors will occur. I check and analyse the source code of medit.c. the code fragment is listed as follows.

if defined(__rtems__)

case ctrl(‘w’): ed = ed->env->current; close_editor(ed); break;

else

case ctrl(‘w’): close_editor(ed); ed = ed->env->current; break;

endif

static void close_editor(struct editor *ed) { struct env *env = ed->env; if (ed->dirty) { display_message(ed, “Close %s without saving changes (y/n)? “, ed->filename); if (!ask()) { ed->refresh = 1; return; } }

delete_editor(ed);

ed = env->current; if (!ed) { ed = create_editor(env); new_file(ed, “”); } ed->refresh = 1; }

static void delete_editor(struct editor ed) { if (ed->next == ed) { ed->env->current = NULL; } else { ed->env->current = ed->prev; } ed->next->prev = ed->prev; ed->prev->next = ed->next; if (ed->start) free(ed->start); clear_undo(ed); * free(ed);** }

as seen above, if the macro __rtems__ is defined. the delete_editor function will free ed pointer. Therefore, after the next loop, the ed is an invalid pointer.I have checked the code of https://github.com/ringgaard/sanos/blob/master/src/utils/edit/edit.c. the code is as follows. case ctrl(‘w’): close_editor(ed); ed = ed->env->current; break;

Author: Chris Johns

2022-11-10T00:52:24.000Z

Original author: chenjin_zhong

  • Milestone changed from %”5.1” to %”5.3”

Author: Chris Johns

2023-01-30T02:39:45.000Z

Original author: chenjin_zhong

The original code is wrong and the change made by Joel due to Coverity is also wrong because the ed passed into close_editor() is the next editor and not the one we want closed.

Author: Trac Migrate

2023-01-31T05:20:41.000Z

Original author: chenjin_zhong

  • Owner set to Chris Johns <chrisj@rtems.org>

  • Resolution set to ~”fixed”

  • Status changed from new to closed

In [changeset:”45f60cfbcff6ab714c441d6c87b6ff919f02f49f/rtems” 45f60cf/rtems]:

libmisc/shell/edit: Fix closing the editor

Closes #4564

Author: Gedare Bloom

2025-06-10T15:03:17.766Z

changed the description

Author: Gedare Bloom

2025-06-10T15:03:20.352Z

mentioned in issue #4834

4559 - ln command problem in shell of RTEMS4.13/5.1

Id

4559

State

closed

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Trac Migrate

Created

2021-12-02T15:47:45.000Z

Updated

2025-09-19T01:22:29.956Z

Milestone

5.3

Labels

cpukit::shell, priority::normal, resolution::wontfix, rtems::shell, tickettype::defect, version::5

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4559

Merges

0

Original author: chenjin_zhong

Hi, when I use ln -s /tmp/file in shell. Ithink the meaning of this instruction is to creates a symbolic link, which points to /tmp/file in current directory.But I find that the code implements this function is **exit(linkit(globals, argv[0], “.”, 1)). ** The src code of linkit function is listed as follows.

int linkit(rtems_shell_ln_globals* globals, const char source, const char *target, int isdir). if (isdir || (!lstat(source, &sb) && S_ISDIR(sb.st_mode)) || (!hflag && !stat(source, &sb) && S_ISDIR(sb.st_mode))) { if ((p = strrchr(target, ‘/’)) == NULL) p = target; else ++p; (void)snprintf(path, sizeof(path), “%s/%s”, source, p); **source = path;* } if ((*linkf)(target, source)) { warn(“%s”, source); return (1); } As shown in black bold, variable source is a directory. Therefore, I think the target is argv[0]. the source is “.”. Therefore, the code exit(linkit(globals, argv[0], “.”, 1)) should be replaced with exit(linkit(globals, “.”,argv[0], 1)).

Author: Chris Johns

2022-11-10T00:51:03.000Z

Original author: chenjin_zhong

  • Milestone changed from %”5.1” to %”5.3”

Author: Chris Johns

2023-01-30T02:32:20.000Z

Original author: chenjin_zhong

The latest code in FreeBSD has the values swapped:

https://github.com/freebsd/freebsd-src/blob/main/bin/ln/ln.c#L152 https://github.com/freebsd/freebsd-src/blob/main/bin/ln/ln.c#L225

Can we swap them in a release or will that break existing scripts?

Author: Chris Johns

2023-02-08T03:15:24.000Z

Original author: chenjin_zhong

  • Resolution set to ~”wontfix”

  • Status changed from new to closed

I am closing this because the change will not be backwards compatible to 5.2 and 5.1. It is suitable for 6.

Author: Gedare Bloom

2025-06-10T15:03:13.650Z

changed the description

4558 - chmod problem in shell of RTEMS4.13/RTEMS5.1

Id

4558

State

closed

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Trac Migrate

Created

2021-12-02T14:53:45.000Z

Updated

2025-09-19T01:22:15.871Z

Milestone

5.3

Labels

cpukit::shell, priority::normal, resolution::fixed, rtems::shell, tickettype::defect, version::5

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4558

Merges

1

Original author: chenjin_zhong

Hi, I find one problem in rtems_shell_main_chmod function. the usage of this instruction is descripted as “chmod 0777 n1 n2… #change filemode”, .the src code is listed as follows. the bold part should be replaced with chmod(argv[n], mode)?

static int rtems_shell_main_chmod(
int argc,
char *argv[]
)
{
int           n;
mode_t        mode;
unsigned long tmp;

if (argc < 2) {
fprintf(stderr,"%s: too few arguments\\n", argv[0]);
return -1;
}

/*
*  Convert arguments into numbers
*/
if ( rtems_string_to_unsigned_long(argv[1], &tmp, NULL, 0) ) {
printf( "Mode argument (%s) is not a number\\n", argv[1] );
return -1;
}
mode = (mode_t) (tmp & 0777);

/*
*  Now change the files modes
*/
for (n=2 ; n < argc ; n++)
chmod(argv[n++], mode); /* <<<< here */

return 0;
}

Author: Chris Johns

2022-11-10T00:49:01.000Z

Original author: chenjin_zhong

  • Description changed

Hi, I find one problem in rtems_shell_main_chmod function. the usage of this instruction is descripted as  "chmod 0777 n1 n2... #change filemode", .the src code is listed as follows. the bold part should be replaced with **chmod(argv[n], mode)**?

-
+ {{{
static int rtems_shell_main_chmod(
int argc,
char *argv[]
)
{
int           n;
mode_t        mode;
unsigned long tmp;

if (argc < 2) {
fprintf(stderr,"%s: too few arguments\\n", argv[0]);
return -1;
}

/*
*  Convert arguments into numbers
*/
if ( rtems_string_to_unsigned_long(argv[1], &tmp, NULL, 0) ) {
printf( "Mode argument (%s) is not a number\\n", argv[1] );
return -1;
}
mode = (mode_t) (tmp & 0777);

/*
*  Now change the files modes
*/
for (n=2 ; n < argc ; n++)
-    ** chmod(argv[n++], mode);**
?    --

+     chmod(argv[n++], mode); /* <<<< here */
?                            ++ +++++++++++ +


return 0;
}
+ }}}
  • Milestone changed from %”5.1” to %”5.3”

This is also valid on main.

Author: Trac Migrate

2023-01-31T05:20:39.000Z

Original author: chenjin_zhong

  • Owner set to Chris Johns <chrisj@rtems.org>

  • Resolution set to ~”fixed”

  • Status changed from new to closed

In [changeset:”2243fd6d6b2faa7f7f734c8bcc6c320b34a160cb/rtems” 2243fd6/rtems]:

libmisc/shell/chmod: Fix multiple file arguments to the command

Closes #4558

Author: Gedare Bloom

2025-06-10T15:03:13.114Z

changed the description

Author: Gedare Bloom

2025-06-10T15:03:18.936Z

mentioned in issue #4751

4555 - Remove aarch64 and microblaze from RSB on 5 branch

Id

4555

State

closed

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Trac Migrate

Created

2021-12-01T16:38:37.000Z

Updated

2025-09-19T01:21:58.343Z

Milestone

5.3

Labels

priority::normal, resolution::fixed, tickettype::defect, tool::rtems-source-builder, version::5

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4555

Merges

0

Original author: rlong

These tools don’t have a port to RTEMS 5, so there’s no reason for them to be on the 5 branch.

Author: Trac Migrate

2021-12-17T15:24:08.000Z

Original author: rlong

  • Milestone changed from %”5.1” to %”Indefinite”

Author: Joel Sherrill

2021-12-17T15:35:56.000Z

Original author: rlong

  • Milestone changed from %”Indefinite” to %”5.2”

Should be 5.2 not Indefinite

Author: Chris Johns

2022-11-09T22:36:10.000Z

Original author: rlong

This was changed to 5.2 last year. Should it be closed?

Author: Chris Johns

2022-12-06T22:47:48.000Z

Original author: rlong

  • Milestone changed from %”5.2” to %”Indefinite”

It is now too late to do this. Please assign a milestone if you wish to do this work.

Author: Joel Sherrill

2022-12-19T21:12:51.000Z

Original author: rlong

  • Milestone changed from %”Indefinite” to %”5.3”

Author: Trac Migrate

2023-01-30T22:46:53.000Z

Original author: rlong

  • Owner set to Joel Sherrill <joel@rtems.org>

  • Resolution set to ~”fixed”

  • Status changed from new to closed

In [changeset:”9144a4ab7f4afb1bf1b66e1686b9eab46c359d67/rtems-source-builder” 9144a4a/rtems-source-builder]:

Remove aarch64 and microblaze from RSB on 5 branch

Closes #4555.

Author: Chris Johns

2025-09-19T01:11:05.768Z

changed the description

4408 - RTEMS ARM Toolchain: armv8.0-m and armv8.1-m arch support

Id

4408

State

closed

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Trac Migrate

Created

2021-05-12T09:47:13.000Z

Updated

2025-09-19T01:21:24.977Z

Milestone

5.3

Labels

priority::normal, resolution::wontfix, tickettype::enhancement, version::5

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4408

Merges

0

Original author: tigrant

Dear RTMES OS devel team,

The RTEMS ARM latest toolchain (based on v5.1 release) supports cortex-m7 which is using armv7-m architecture.

Are you planning to upgrade your toolchain version and add support for cortex-m33 and cortex-m55 CPUs which are using armv8.0-m and armv8.1-m architectures ?

Thank you.

Best Regards, Tigran

Author: Joel Sherrill

2021-05-12T14:52:52.000Z

Original author: tigrant

If you need a newer toolchain, you should use rtems6 (e.g. git master). It is using gcc 10.

We tend to not update the toolchains for release branches. And newer architecture versions would also be added to master, not the release branch.

Are there specific deficiencies on the master and its tool chain?

Author: Trac Migrate

2021-05-12T16:04:48.000Z

Original author: tigrant

Hi Joel,

Thank you very much for your response.

As far as I understand “git master” contains only RTMES kernel source code, but not a toolchain. (please correct me if I wrong)

Would you please clarify where from can I get the newer RTEMS GCC 10 based toolchain ? For example, for release 5.1.0 I have used RTEMS v5 RSB to build the toolchain. How can I build newer GCC 10 based toolchain without having corresponding RTEMS v6 RSB ? (As I know RTEMS using customised version of toolchain based on GCC and I have to compile RTEMS kernel using RTEMS toolchain).

Would you please advise ? Thank you.

Best Regards, Tigran

Author: Joel Sherrill

2021-05-12T16:35:42.000Z

Original author: tigrant

There is no GCC 10 RSB recipe for RTEMS 5. You could modify the arm gcc version in your local 5 branch based on what is in 6. You will need to keep the newlib version the same, but the gcc should be able to be changed.

I don’t know what it would be called but a more bleeding edge gcc might be nice for a release branch. For rtems master, we refer to that as rtems7.

For sure, updating GCC past 7 on rtems5 will break some BSPs. At least some PowerPC BSPs need SPE support which was dropped after 7 and I think the ARM changed some compiler flags. But, in theory, there isn’t anything wrong with having a newer GCC as an alternative. But it would have to be disclaimed that all testing for the release was done with GCC 7 and anything newer would be at some risk of breakage. And I don’t know what the toolchain would be called. It isn’t 6 and isn’t 5.

Author: Trac Migrate

2021-05-12T17:03:40.000Z

Original author: tigrant

Hi Joel,

Thanks a lot. I will change the GCC version in rtems-source-builder-5.1 to gcc 10.x and will try to build the new toolchain. After that will try to compile the latest “git master”.

May I ask you please to clarity the sentence: “You could modify the arm gcc version in your local 5 branch based on what is in 6.” ?

Best Regards, Tigran

Author: Chris Johns

2022-11-10T00:12:54.000Z

Original author: tigrant

  • Milestone changed from %”5.1” to %”5.3”

  • Resolution set to ~”wontfix”

  • Status changed from new to closed

Please reopen if this is an issue or please ask on the users list if help is needed.

Author: Chris Johns

2025-09-19T01:10:59.508Z

changed the description

4565 - medit malloc problem of RTEMS5.1

Id

4565

State

closed

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Trac Migrate

Created

2021-12-05T14:19:24.000Z

Updated

2025-09-19T01:20:47.935Z

Milestone

5.3

Labels

cpukit::shell, priority::normal, resolution::fixed, rtems::shell, tickettype::enhancement, version::5

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4565

Merges

1

Original author: chenjin_zhong

I find malloc function is called by move_gap function in medit.c. The returned value does not check. At least 32KB of memory is allocated at each time, maybe more than. The returned value “start” should be check to avoid malloc failure. The move_gap function should return immediatelty when malloc failure. the code frament is listed as follows.

static void move_gap(struct editor *ed, int pos, int minsize) { int gapsize = ed->rest - ed->gap; unsigned char *p = text_ptr(ed, pos); if (minsize < 0) minsize = 0; if (minsize <= gapsize) { if (p != ed->rest) { if (p < ed->gap) { memmove(p + gapsize, p, ed->gap - p); } else { memmove(ed->gap, ed->rest, p - ed->rest); } ed->gap = ed->start + pos; ed->rest = ed->gap + gapsize; } } else { int newsize; unsigned char *start; unsigned char *gap; unsigned char *rest; unsigned char *end;

if (gapsize + MINEXTEND > minsize) minsize = gapsize + MINEXTEND; newsize = (ed->end - ed->start) - gapsize + minsize; ** start = (unsigned char ) malloc(newsize);* // TODO check for out of memory gap = start + pos; rest = gap + minsize; end = start + newsize;

if (p < ed->gap) { memcpy(start, ed->start, pos); memcpy(rest, p, ed->gap - p); memcpy(end - (ed->end - ed->rest), ed->rest, ed->end - ed->rest); } else { memcpy(start, ed->start, ed->gap - ed->start); memcpy(start + (ed->gap - ed->start), ed->rest, p - ed->rest); memcpy(rest, p, ed->end - p); }

free(ed->start); ed->start = start; ed->gap = gap; ed->rest = rest; ed->end = end; }

ifdef DEBUG

memset(ed->gap, 0, ed->rest - ed->gap);

endif

}

Author: Chris Johns

2022-11-10T00:54:28.000Z

Original author: chenjin_zhong

  • Milestone changed from %”5.1” to %”5.3”

Author: Trac Migrate

2023-01-31T05:20:44.000Z

Original author: chenjin_zhong

  • Owner set to Chris Johns <chrisj@rtems.org>

  • Resolution set to ~”fixed”

  • Status changed from new to closed

In [changeset:”b7f1fa2f89244347472fa1f6829287bcab285730/rtems” b7f1fa2f/rtems]:

libmisc/shell/edit: Return if no memory in move_gap

Closes #4565

Author: Gedare Bloom

2025-06-10T15:03:14.107Z

changed the description

Author: Gedare Bloom

2025-06-10T15:03:16.386Z

mentioned in issue #4835

4777 - Deployed RSB does not find release version config

Id

4777

State

closed

Type

ISSUE

Author

Chris Johns

Assignee(s)

Chris Johns

Created

2022-12-18T03:40:53.000Z

Updated

2025-09-19T01:20:02.688Z

Milestone

5.3

Labels

priority::normal, resolution::fixed, tickettype::defect, tool::rtems-source-builder, version::5

Link

https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/4777

Merges

0

The RSB does not find the VERSION file when released.

Author: Trac Migrate

2022-12-18T04:50:27.000Z

  • Resolution set to ~”fixed”

  • Status changed from assigned to closed

In [changeset:”c665be18f6c282b89226fded29a7d146f8b540d3/rtems-source-builder” c665be1/rtems-source-builder]:

sb: Find the top when a release

Closes #4777

Author: Chris Johns

2025-09-19T01:11:15.076Z

changed the description