[PATCH] riscv: Make sifive_test finisher 4 bytes
QEMU is now stricter with MMIO sizes and accesses. uintptr_t on RV64
is 8 bytes and generates an sd instruction that Store/AMO faults
because sifive_test MMIO expects 4 bytes accesses.
---
bsps/riscv/riscv/start/bsp_fatal_halt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/riscv/riscv/start/bsp_fatal_halt.c
b/bsps/riscv/riscv/start/bsp_fatal_halt.c
index af9e2ac7c6..348fa4f8f4 100644
--- a/bsps/riscv/riscv/start/bsp_fatal_halt.c
+++ b/bsps/riscv/riscv/start/bsp_fatal_halt.c
@@ -35,7 +35,7 @@ void _CPU_Fatal_halt(uint32_t source, uint32_t error)
{
const char *fdt;
int node;
- volatile uintptr_t *sifive_test;
+ volatile uint32_t *sifive_test;
#if RISCV_ENABLE_HTIF_SUPPORT != 0
htif_poweroff();
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 14/9/20 5:07 pm, Sebastian Huber wrote: > I checked in the new build system today. Now is a good time to test your > favourite BSP if it still works. Thank you for this work. It is really great. Do you have any thoughts on how we track which BSPs have been looked at and are OK? What do I need to do to say a BSP is OK? Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 15/09/2020 09:09, Chris Johns wrote: On 14/9/20 5:07 pm, Sebastian Huber wrote: I checked in the new build system today. Now is a good time to test your favourite BSP if it still works. Thank you for this work. It is really great. Do you have any thoughts on how we track which BSPs have been looked at and are OK? What do I need to do to say a BSP is OK? In theory we could use the same approach as we did using the old build system. We report the test results and collect the information to document the tiers. Maybe it is more practical if we add a table to a wiki page in which everyone can add the BSPs which were tested with the new build system. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 9/15/20 9:28 AM, Sebastian Huber wrote: > Maybe it is more practical if we add a table to a wiki page in which > everyone can add the BSPs which were tested with the new build system. I think this would be fantastic to have. Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] riscv: Make sifive_test finisher 4 bytes
On 15/09/2020 09:09, Hesham Almatary wrote: QEMU is now stricter with MMIO sizes and accesses. uintptr_t on RV64 is 8 bytes and generates an sd instruction that Store/AMO faults because sifive_test MMIO expects 4 bytes accesses. Ok. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 15/09/2020 09:32, Karel Gardas wrote: On 9/15/20 9:28 AM, Sebastian Huber wrote: Maybe it is more practical if we add a table to a wiki page in which everyone can add the BSPs which were tested with the new build system. I think this would be fantastic to have. An alternative would be to add it to the ticket as a comment. I can add a table to the ticket description and update the table based on the comments. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 6-freebsd-12 3/4] build: Separate the kernel and user land include paths
On 15/09/2020 04:33, chr...@rtems.org wrote: -def get_includes(self): +def getIncludes(self): I am not sure which coding style the file uses in general, but pylint complains about camelCase function names. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 9/15/20 9:36 AM, Sebastian Huber wrote: > On 15/09/2020 09:32, Karel Gardas wrote: > >> On 9/15/20 9:28 AM, Sebastian Huber wrote: >>> Maybe it is more practical if we add a table to a wiki page in which >>> everyone can add the BSPs which were tested with the new build system. >> I think this would be fantastic to have. > An alternative would be to add it to the ticket as a comment. I can add > a table to the ticket description and update the table based on the > comments. Whatever suites you best, but table is IMHO right way to go on this. Thanks, Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 6-freebsd-12 1/4] waf: Reformat to PEP8 using yapf
The patch set looks good. I only had a brief look at it. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems_task_create_from_config() Name?
On 14/09/2020 06:52, Sebastian Huber wrote: They are created using the words from your sentence above :) My favorite is still rtems_task_build(). Not mine. Do you create, build then start? I think it needs create and it lacks the storage bit. Maybe we should use a synonym of "create" (build is not a synonym of create) such as "make": rtems_task_make() rtems_message_queue_make() With respect to the directive name, what about the "make" variant? I think this avoids a potential create, build then start confusion. We have create then start, or make then start. Maybe another synonym of create like produce, fabricate, construct, forge, ...? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libmisc/monitor: Fix string restrict warning
From: Aschref Ben Thabet
Replace strcpy with the safer memcpy().
The strcpy() function is designed to work exclusively with strings.
strcpy() copies each byte of the source string to the destination string
and stops when the terminating null character (\0) has been moved.
On the other hand, the memcpy() function is designed to work with any
type of data, because not all data ends with a null character, you must
provide the memcpy() function with the number of bytes you want to copy
from the source to the destination.
---
cpukit/libmisc/monitor/mon-editor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpukit/libmisc/monitor/mon-editor.c
b/cpukit/libmisc/monitor/mon-editor.c
index a3b408a14f..e6ead104ca 100644
--- a/cpukit/libmisc/monitor/mon-editor.c
+++ b/cpukit/libmisc/monitor/mon-editor.c
@@ -339,8 +339,8 @@ rtems_monitor_line_editor (
{
int end;
int bs;
- strcpy (&buffer[pos], &buffer[pos + 1]);
- fprintf(stdout,"\r%s $ %s", monitor_prompt, buffer);
+ memcpy(&buffer[pos], &buffer[pos + 1], strlen(&buffer[pos + 1]));
+ fprintf(stdout, "\r%s $ %s", monitor_prompt, buffer);
end = (int) strlen (buffer);
for (bs = 0; bs < (end - pos); bs++)
putchar ('\b');
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Psxtest: Fix String truncation warning
From: Aschref Ben Thabet Replace strncpy() with strdup() to silence this warning since it tries to allocate enough memory to hold the old string (plus a '\0' character to mark the end of the string). --- testsuites/psxtests/psxndbm01/init.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/testsuites/psxtests/psxndbm01/init.c b/testsuites/psxtests/psxndbm01/init.c index a13afa7315..ddcc1b5bf6 100644 --- a/testsuites/psxtests/psxndbm01/init.c +++ b/testsuites/psxtests/psxndbm01/init.c @@ -217,14 +217,9 @@ rtems_task Init(rtems_task_argument ignored) rtems_test_assert( strcmp( (const char*)get_phone_no.dptr, PHONE_NO2 ) == 0 ); puts( "Fetch non-existing record and confirm error." ); - test_strings = (char*)malloc(6); - strncpy( test_strings, "Hello", 5 ); - - test_strings[5] = '\0'; + test_strings = strdup( "Hello" ); /* The data pointed by test_string is now pointed by key.dptr */ - key.dptr = test_strings; - key.dsize = sizeof( test_strings ); get_phone_no = dbm_fetch( db, key ); rtems_test_assert( get_phone_no.dptr == NULL ); dbm_close( db ); @@ -237,10 +232,10 @@ rtems_task Init(rtems_task_argument ignored) db = dbm_open( DB_NAME, O_RDWR, S_IRWXU ); rtems_test_assert( db != NULL ); - puts( "Delete non-existing record and confirm error." ); + /* puts( "Delete non-existing record and confirm error." ); rtems_test_assert( dbm_delete( db, key ) != 0 ); free( test_strings ); - rtems_test_assert( count_no_of_records( db ) == 2); + rtems_test_assert( count_no_of_records( db ) == 2);*/ puts( "Delete existing record and " "confirm that total number of records is successful 1." ); -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libmisc/capture: Fix unaligned pointer value warning
From: Aschref Ben Thabet
Change the function ctrace_task_name_add() to take the variable name as
a value instead a pointer.
It avoids the warning and solve the issue.
---
cpukit/libmisc/capture/capture_support.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpukit/libmisc/capture/capture_support.c
b/cpukit/libmisc/capture/capture_support.c
index 4af8822c79..0877a70160 100644
--- a/cpukit/libmisc/capture/capture_support.c
+++ b/cpukit/libmisc/capture/capture_support.c
@@ -81,7 +81,7 @@ static ctrace_tasks tasks;
* Add a name.
*/
static void
-ctrace_task_name_add (rtems_id id, const rtems_name* name)
+ctrace_task_name_add (rtems_id id, const rtems_name name)
{
if (tasks.tasks == NULL)
{
@@ -97,7 +97,7 @@ ctrace_task_name_add (rtems_id id, const rtems_name* name)
{
if (tasks.tasks[t].id == id)
{
- tasks.tasks[t].name = *name;
+ tasks.tasks[t].name = name;
break;
}
}
@@ -111,7 +111,7 @@ ctrace_task_name_add (rtems_id id, const rtems_name* name)
}
if (tasks.tasks != NULL)
{
- tasks.tasks[tasks.count].name = *name;
+ tasks.tasks[tasks.count].name = name;
tasks.tasks[tasks.count].id = id;
++tasks.count;
}
@@ -349,7 +349,7 @@ rtems_capture_print_trace_records (int total, bool csv)
cpu->recs = rtems_capture_record_extract (cpu->recs,
&task_rec,
sizeof (task_rec));
-ctrace_task_name_add (rec_out->task_id, &task_rec.name);
+ctrace_task_name_add(rec_out->task_id, task_rec.name);
rtems_capture_print_record_task (cpu_out, rec_out, &task_rec);
}
else
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] testsuites/fstests/dos: Fix format truncation warning
From: Aschref Ben Thabet
Replace the snprintf() code line with memcpy() and strcpy(). First copy
the MOUNT_DIR to dirname and add the '/' character, then copy the
invalide directory name.
---
testsuites/fstests/fsdosfsname01/init.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/testsuites/fstests/fsdosfsname01/init.c
b/testsuites/fstests/fsdosfsname01/init.c
index 3689da8eed..38ad8dd7c8 100644
--- a/testsuites/fstests/fsdosfsname01/init.c
+++ b/testsuites/fstests/fsdosfsname01/init.c
@@ -423,14 +423,11 @@ static void test_creating_invalid_directories( void )
int rc;
char dirname[MAX_NAME_LENGTH_INVALID + MOUNT_DIR_SIZE + 1];
-
for ( index = 0; index < NUMBER_OF_DIRECTORIES_INVALID; ++index ) {
-snprintf( dirname,
- sizeof( dirname ),
- "%s/%s",
- MOUNT_DIR,
- DIRECTORY_NAMES_INVALID[index] );
-rc = mkdir( dirname, S_IRWXU | S_IRWXG | S_IRWXO );
+memcpy( dirname, MOUNT_DIR, MOUNT_DIR_SIZE - 1);
+dirname[MOUNT_DIR_SIZE - 1] = '/';
+strcpy( dirname + MOUNT_DIR_SIZE, DIRECTORY_NAMES_INVALID[index]);
+rc = mkdir(dirname, S_IRWXU | S_IRWXG | S_IRWXO);
rtems_test_assert( rc == -1 );
}
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] testsuits/dl10 : Prototype missing
From: Aschref Ben Thabet
Add a prototype for the function rtems_main_o5() to avoid the prototype
missing warning.
---
testsuites/libtests/dl10/dl10-o6.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/testsuites/libtests/dl10/dl10-o6.c
b/testsuites/libtests/dl10/dl10-o6.c
index ab6deb189d..e40bdfc46a 100644
--- a/testsuites/libtests/dl10/dl10-o6.c
+++ b/testsuites/libtests/dl10/dl10-o6.c
@@ -11,7 +11,8 @@
#include
#include
-int rtems_main_o5 (void)
+int rtems_main_o5(void);
+int rtems_main_o5(void)
{
/* duplicate symbol in archive */
return 0;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning
From: Aschref Ben Thabet
Taking care of the size of buffer to be copied and replace the unsafe
snprintf() with memcpy().
The reason why we get a warning on sprintf() is because memcpy() has a
length parameter that limits how much memory you copy.
For memcpy(), the input has to be terminated with a \0. If not, it will
continue out of bounds.
---
cpukit/mghttpd/mongoose.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/cpukit/mghttpd/mongoose.c b/cpukit/mghttpd/mongoose.c
index fb2bce7471..6db0bdb58e 100644
--- a/cpukit/mghttpd/mongoose.c
+++ b/cpukit/mghttpd/mongoose.c
@@ -251,7 +251,7 @@ typedef struct DIR {
#define INT64_FMT PRId64
typedef int SOCKET;
#define WINCDECL
-
+#define MIN(a, b)((a) < (b) ? (a) : (b))
#endif // End of Windows and UNIX specific includes
#ifndef HAVE_POLL
@@ -1916,12 +1916,24 @@ static void convert_uri_to_file_name(struct
mg_connection *conn, char *buf,
// we can only do this if the browser declares support
if ((accept_encoding = mg_get_header(conn, "Accept-Encoding")) != NULL) {
if (strstr(accept_encoding,"gzip") != NULL) {
- snprintf(gz_path, sizeof(gz_path), "%s.gz", buf);
- if (mg_stat(conn, gz_path, filep)) {
-filep->gzipped = 1;
-return;
+ memcpy(gz_path, buf, MIN(strlen(buf) + 1, sizeof(gz_path)));
+ if (strlen(buf) > sizeof(gz_path) - 1)
+ strlcpy(gz_path + strlen(gz_path), ".gz", sizeof(gz_path) -
strlen(gz_path));
+ /* else //to be reviewed /
+ {
+ //memory allocation for gz.path with buf_size + .gz
+ mount_path = malloc(strlen(buf) + 1 + sizeof(gz_path);
+ if (mount_path != NULL))
+strlcpy(mount_path, ".gz", sizeof(mount_path));
+ }
+ snprintf(gz_path, sizeof(gz_path), "%s.gz", buf*)
+*/
+ if (mg_stat(conn, gz_path, filep))
+{
+ filep->gzipped = 1;
+ return;
+}
}
-}
}
// Support PATH_INFO for CGI scripts.
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libmisc/shell/shell.c: Fix restrict warning
From: Aschref Ben Thabet
Replace the unsafe function strcpy() with memmove() to avoid the string
restrict warning.
Since memmove() function is used to copy a specified number of bytes
from one memory to another or to overlap on same memory.
---
cpukit/libmisc/shell/shell.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/cpukit/libmisc/shell/shell.c b/cpukit/libmisc/shell/shell.c
index 13ae411f9c..36eac3d14f 100644
--- a/cpukit/libmisc/shell/shell.c
+++ b/cpukit/libmisc/shell/shell.c
@@ -393,7 +393,7 @@ static int rtems_shell_line_editor(
{
int end;
int bs;
-strcpy (&line[col], &line[col + 1]);
+memmove(line + col, line + col + 1, strlen(line + col + 1) + 1);
if (output) {
fprintf(out,"\r%s%s ", prompt, line);
end = (int) strlen (line);
@@ -432,7 +432,7 @@ static int rtems_shell_line_editor(
case 4: /* Control-D */
if (strlen(line)) {
if (col < strlen(line)) {
- strcpy (line + col, line + col + 1);
+ memmove(line + col, line + col + 1, strlen(line + col + 1) + 1);
if (output) {
int bs;
fprintf(out,"%s \b", line + col);
@@ -508,7 +508,7 @@ static int rtems_shell_line_editor(
{
int bs;
col--;
-strcpy (line + col, line + col + 1);
+memmove(line + col, line + col + 1, strlen(line + col + 1));
if (output) {
fprintf(out,"\b%s \b", line + col);
for (bs = 0; bs < ((int) strlen (line) - col); bs++)
@@ -620,9 +620,9 @@ static int rtems_shell_line_editor(
case 21:/* Control-U */
if (col > 0)
{
-int clen = strlen (line);
+size_t clen = strlen (line);
-strcpy (line, line + col);
+memmove(line, line + col, strlen(line + col) + 1);
if (output) {
fprintf(out,"\r%s%*c", prompt, clen, ' ');
fprintf(out,"\r%s%s", prompt, line);
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libmisc/shell: Fix string truncation warning
From: Aschref Ben Thabet
Strncpy() is considered unsafe as the resulting string may not be NULL
terminated. In addition it fills the unused part of the destination
buffer unnecessarily with NULL bytes.
Strlcpy() is designed to solve the null-termination problemsi,it always
null-terminates.
It’s certainly an improvement over strncpy().
---
cpukit/libmisc/shell/main_edit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/cpukit/libmisc/shell/main_edit.c b/cpukit/libmisc/shell/main_edit.c
index e43ff68d2b..6075bf8bfa 100644
--- a/cpukit/libmisc/shell/main_edit.c
+++ b/cpukit/libmisc/shell/main_edit.c
@@ -286,8 +286,7 @@ static struct editor *find_editor(struct env *env, char
*filename) {
struct editor *ed = env->current;
struct editor *start = ed;
- if (!realpath(filename, fn)) strncpy(fn, filename, FILENAME_MAX);
-
+ if (!realpath(filename, fn)) strlcpy(fn, filename, sizeof(fn));
do {
if (strcmp(fn, ed->filename) == 0) return ed;
ed = ed->next;
@@ -297,7 +296,7 @@ static struct editor *find_editor(struct env *env, char
*filename) {
static int new_file(struct editor *ed, char *filename) {
if (*filename) {
-strncpy(ed->filename, filename, FILENAME_MAX);
+ strlcpy(ed->filename, filename, sizeof(ed->filename));
} else {
sprintf(ed->filename, "Untitled-%d", ++ed->env->untitled);
ed->newfile = 1;
@@ -1775,8 +1774,9 @@ static void save_editor(struct editor *ed) {
return;
}
}
-strncpy(
- ed->filename, (const char*) ed->env->linebuf, FILENAME_MAX);
+
+strlcpy(
+ed->filename, (const char*)ed->env->linebuf, sizeof(ed->filename));
ed->newfile = 0;
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libmisc/monitor: Fix string restrict warning
On 15/09/2020 11:02, Aschref Ben-Thabet wrote:
From: Aschref Ben Thabet
Replace strcpy with the safer memcpy().
The strcpy() function is designed to work exclusively with strings.
strcpy() copies each byte of the source string to the destination string
and stops when the terminating null character (\0) has been moved.
On the other hand, the memcpy() function is designed to work with any
type of data, because not all data ends with a null character, you must
provide the memcpy() function with the number of bytes you want to copy
from the source to the destination.
---
cpukit/libmisc/monitor/mon-editor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpukit/libmisc/monitor/mon-editor.c
b/cpukit/libmisc/monitor/mon-editor.c
index a3b408a14f..e6ead104ca 100644
--- a/cpukit/libmisc/monitor/mon-editor.c
+++ b/cpukit/libmisc/monitor/mon-editor.c
@@ -339,8 +339,8 @@ rtems_monitor_line_editor (
{
int end;
int bs;
- strcpy (&buffer[pos], &buffer[pos + 1]);
- fprintf(stdout,"\r%s $ %s", monitor_prompt, buffer);
+ memcpy(&buffer[pos], &buffer[pos + 1], strlen(&buffer[pos + 1]));
+ fprintf(stdout, "\r%s $ %s", monitor_prompt, buffer);
This fix makes no sense. Using strcpy() or memcpy() on overlapping
memory areas is undefined behavior.
You probably need an memmove(). Since there are similar issues on other
places didn't we discuss to add a helper function to this file?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Fix fdt string warnings
From: Aschref Ben Thabet --- cpukit/libmisc/rtems-fdt/rtems-fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/libmisc/rtems-fdt/rtems-fdt.c b/cpukit/libmisc/rtems-fdt/rtems-fdt.c index 39e70bffec..d2b412ceb0 100644 --- a/cpukit/libmisc/rtems-fdt/rtems-fdt.c +++ b/cpukit/libmisc/rtems-fdt/rtems-fdt.c @@ -264,7 +264,7 @@ rtems_fdt_index_find_by_name(rtems_fdt_index* index, namelen = sizeof(path) - 1; } -strncpy(path, name, namelen); +memcpy(path, name, namelen); path[namelen] = 0; cmp_name = path; } -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libblock/bdpart-register.c: Fix string truncation warning.
From: Aschref Ben Thabet
Replace strncpy() with memcpy() to guarantee a safe copying of
characters.
---
cpukit/libblock/src/bdpart-mount.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/cpukit/libblock/src/bdpart-mount.c
b/cpukit/libblock/src/bdpart-mount.c
index cfc08ead30..dd4c09c59e 100644
--- a/cpukit/libblock/src/bdpart-mount.c
+++ b/cpukit/libblock/src/bdpart-mount.c
@@ -54,7 +54,7 @@ rtems_status_code rtems_bdpart_mount(
if (logical_disk_name == NULL) {
return RTEMS_NO_MEMORY;
}
- strncpy( logical_disk_name, disk_name, disk_name_size);
+ memcpy(logical_disk_name, disk_name, disk_name_size);
/* Get disk file name */
if (disk_file_name != NULL) {
@@ -71,9 +71,8 @@ rtems_status_code rtems_bdpart_mount(
esc = RTEMS_NO_MEMORY;
goto cleanup;
}
- strncpy( mount_point, mount_base, mount_base_size);
- mount_point [mount_base_size] = '/';
- strncpy( mount_point + mount_base_size + 1, disk_file_name,
disk_file_name_size);
+ memcpy(mount_point, mount_base, mount_base_size);
+ memcpy(mount_point + mount_base_size + 1, disk_file_name,
disk_file_name_size);
/* Markers */
logical_disk_marker = logical_disk_name + disk_name_size;
@@ -89,7 +88,7 @@ rtems_status_code rtems_bdpart_mount(
}
/* Create mount point */
-strncpy( mount_marker, logical_disk_marker, RTEMS_BDPART_NUMBER_SIZE);
+memcpy( mount_marker, logical_disk_marker, RTEMS_BDPART_NUMBER_SIZE);
rv = rtems_mkdir( mount_point, S_IRWXU | S_IRWXG | S_IRWXO);
if (rv != 0) {
esc = RTEMS_IO_ERROR;
@@ -148,9 +147,8 @@ rtems_status_code rtems_bdpart_unmount(
esc = RTEMS_NO_MEMORY;
goto cleanup;
}
- strncpy( mount_point, mount_base, mount_base_size);
- mount_point [mount_base_size] = '/';
- strncpy( mount_point + mount_base_size + 1, disk_file_name,
disk_file_name_size);
+ memcpy(mount_point, mount_base, mount_base_size);
+ memcpy( mount_point + mount_base_size + 1, disk_file_name,
disk_file_name_size);
/* Marker */
mount_marker = mount_point + mount_base_size + 1 + disk_file_name_size;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit/libblock/bdpart-register.c: Fix string truncation warning.
From: Aschref Ben Thabet
Replace strncpy() with memcpy() to guarantee a safe copying of
characters.
---
cpukit/libblock/src/bdpart-register.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cpukit/libblock/src/bdpart-register.c
b/cpukit/libblock/src/bdpart-register.c
index 9956e61a68..8a1de6135e 100644
--- a/cpukit/libblock/src/bdpart-register.c
+++ b/cpukit/libblock/src/bdpart-register.c
@@ -38,7 +38,7 @@ static char *create_logical_disk_name( const char *disk_name,
char **marker)
char *logical_disk_name = malloc( disk_name_size + RTEMS_BDPART_NUMBER_SIZE);
if (logical_disk_name != NULL) {
-strncpy( logical_disk_name, disk_name, disk_name_size);
+memcpy( logical_disk_name, disk_name, disk_name_size);
*marker = logical_disk_name + disk_name_size;
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] display/disp_hcms29xx: Fix string truncation warning
From: Aschref Ben Thabet
Strncpy() is unsafe if the terminating NUL is missing. Replace it by the
safer strlcpy() and fix the string truncation warning,since the
strlcpy() function returns the total length of the string it tried to
create,that means: the length of src.
---
bsps/shared/dev/display/disp_hcms29xx.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/bsps/shared/dev/display/disp_hcms29xx.c
b/bsps/shared/dev/display/disp_hcms29xx.c
index 5730b36ea9..fb88f66343 100644
--- a/bsps/shared/dev/display/disp_hcms29xx.c
+++ b/bsps/shared/dev/display/disp_hcms29xx.c
@@ -589,10 +589,9 @@ static rtems_task disp_hcms29xx_update_task
RTEMS_WAIT,RTEMS_NO_TIMEOUT);
}
if (rc == RTEMS_SUCCESSFUL) {
- strncpy(softc_ptr->disp_param.disp_buffer,
+ strlcpy(softc_ptr->disp_param.disp_buffer,
softc_ptr->disp_param.trns_buffer,
sizeof(softc_ptr->disp_param.disp_buffer));
-
softc_ptr->disp_param.disp_buffer[sizeof(softc_ptr->disp_param.disp_buffer)-1]
= '\0';
softc_ptr->disp_param.disp_buf_cnt =
(int) strlen(softc_ptr->disp_param.disp_buffer);
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] rtems/printer.h: Fix build warnings -Wclass-memaccess
From: Aschref Ben Thabet
Cast to (void *) to silence the warning.
---
cpukit/include/rtems/printer.h | 4
1 file changed, 4 deletions(-)
diff --git a/cpukit/include/rtems/printer.h b/cpukit/include/rtems/printer.h
index 310937cc2f..25c6f27960 100644
--- a/cpukit/include/rtems/printer.h
+++ b/cpukit/include/rtems/printer.h
@@ -130,10 +130,6 @@ static inline void rtems_printer_task_initialize(
rtems_printer_task_context *context
)
{
- /*
- * Some C++ compiler think that the structure is complex enough to need a
- * proper constructor. Cast to void * to silence a warning.
- */
memset( (void *) context, 0, sizeof( *context ) );
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: PATCHes
Dear Rtems Developers, since I have sent the patches too early without testing and verifying them, I apologize about this mistake. Please ignore the patches which I have sent today. I will send new patches as soon as I finish testing them. Sorry about this inconvenience ! Best regards, Aschref Ben Thabet Embedded Brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
I am developing applications in rtems 5.1. As we know, my application and rtems kernel are both in the same address space. So if my application access an invalid address or encounter other fatal errors, I want the kernel not just being hunging, but create a core dump file. This file contains the whole contents of memory and I could use a debuger to analyse the file to handle the bug. The question arise because I do not want always debug rtems in the bsp. small...@aliyun.com ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 6-freebsd-12 3/4] build: Separate the kernel and user land include paths
> On 15 Sep 2020, at 5:51 pm, Sebastian Huber > wrote: > > On 15/09/2020 04:33, chr...@rtems.org wrote: > >> -def get_includes(self): >> +def getIncludes(self): > I am not sure which coding style the file uses in general, but pylint > complains about camelCase function names. I did not run pylint, I only ran yapf. I followed the convention in the file. Is this wrong? This code does need pylint run on it but I do not have the time. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 6-freebsd-12 3/4] build: Separate the kernel and user land include paths
On 15/09/2020 13:01, Chris Johns wrote: On 15 Sep 2020, at 5:51 pm, Sebastian Huber wrote: On 15/09/2020 04:33,chr...@rtems.org wrote: -def get_includes(self): +def getIncludes(self): I am not sure which coding style the file uses in general, but pylint complains about camelCase function names. I did not run pylint, I only ran yapf. I followed the convention in the file. Is this wrong? Before I used pylint, I used CamalCase for Python code, but then learned that pylint is not happy about this. This code does need pylint run on it but I do not have the time. Yes, no problem. It is just something I noticed. The patch is fine as it is. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
build: i386/pc686/appstart.o is created more than once
Hello, please have a look at: https://devel.rtems.org/ticket/4079 I have no idea how this can be done in waf. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 6-freebsd-12 3/4] build: Separate the kernel and user land include paths
On 15/09/2020 16:48, Joel Sherrill wrote: Otherwise, I am just asking does Python code need to pass. pylint and yapf are mentioned in this thread but https://books.agiliq.com/projects/essential-python-tools/en/latest/linters.html has a list of tools and claims that pycodelint matches pep8. I thought we were trying to follow pep8. It also mentions pyflake which sounds useful. What is the recommended set of tools to pass and with what settings? I know we aren't completely passing on all Python code but what's the objective from a tool checking viewpoint. The Python code in rtems-central uses flake8, pylint and mypy with default settings. It seems our guide lines are in line with what you cited above: https://docs.rtems.org/branches/master/eng/python-devel.html ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] riscv: Make sifive_test finisher 4 bytes
On Tue, Sep 15, 2020 at 1:33 AM Sebastian Huber wrote: > > On 15/09/2020 09:09, Hesham Almatary wrote: > > > QEMU is now stricter with MMIO sizes and accesses. uintptr_t on RV64 > > is 8 bytes and generates an sd instruction that Store/AMO faults > > because sifive_test MMIO expects 4 bytes accesses. > Ok. This is definitely a type mismatch. The uintptr_t* should only be used to point to something that is a memory address. > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
No, there is no facility to generate a core dump. Due to shared address space, once there is a fatal error you can't really trust anything running in the target. You wouldn't necessarily want to try writing to a mounted filesystem. You could probably set up a debugger to do something like this by triggering it in the fatal exception handler. You'd need to make use of whatever the debugger can do already though. You really can't rely on the executing target. Gedare On Tue, Sep 15, 2020 at 4:58 AM small...@aliyun.com wrote: > > I am developing applications in rtems 5.1. As we know, my application and > rtems kernel are both in the same address space. > So if my application access an invalid address or encounter other fatal > errors, I want the kernel not just being hunging, but create a core dump file. > This file contains the whole contents of memory and I could use a debuger to > analyse the file to handle the bug. > The question arise because I do not want always debug rtems in the bsp. > > > small...@aliyun.com > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: New build system ready for testing
This is great news as the AArch64 work I've been doing was built on your waf branch and now I can rebase on to mainline code. I had assumed that the old build system would be removed when the new build system got added, but that obviously didn't happen. Will it eventually be removed after a transition period is over or will they both exist and be maintained going forward? Kinsey -Original Message- From: devel On Behalf Of Sebastian Huber Sent: Monday, September 14, 2020 02:08 To: RTEMS Subject: New build system ready for testing Hello, I checked in the new build system today. Now is a good time to test your favourite BSP if it still works. You find the user oriented documentation of build system here: https://docs.rtems.org/branches/master/user/bld/index.html The documentation for RTEMS maintainers is here: https://docs.rtems.org/branches/master/eng/build-system.html How to check the new build system for a particular BSP? 1. Build the BSP with all tests enabled. 2. Run the tests and compare the results with the old build system. Ideally use the RTEMS Tester to run the tests and report them to the RTEMS Project. 3. Check if all BSP options are available (./waf bsp_defaults). Check the type and values of the BSP options. 4. Check the linker command file. 5. Check the compiler machine flags. 6. Install the BSP and build your third-party libraries and applications with it. -- 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
On Tue, Sep 15, 2020 at 10:26 AM Gedare Bloom wrote: > No, there is no facility to generate a core dump. Due to shared > address space, once there is a fatal error you can't really trust > anything running in the target. You wouldn't necessarily want to try > writing to a mounted filesystem. > > You could probably set up a debugger to do something like this by > triggering it in the fatal exception handler. You'd need to make use > of whatever the debugger can do already though. You really can't rely > on the executing target. > On the more popular architectures, if you get an exception, the BSP will print out a lot of information. Included in that is usually the address of the fault and register set. You can use the symbol table (from nm) or addr2line to map that back to source code. Look at the generated assembly and you can often tell what went wrong. Better is to attach a debugger and set a breakpoint on the exception handler address and then poke around to see more details. --joel > > Gedare > > On Tue, Sep 15, 2020 at 4:58 AM small...@aliyun.com > wrote: > > > > I am developing applications in rtems 5.1. As we know, my application > and rtems kernel are both in the same address space. > > So if my application access an invalid address or encounter other fatal > errors, I want the kernel not just being hunging, but create a core dump > file. > > This file contains the whole contents of memory and I could use a > debuger to analyse the file to handle the bug. > > The question arise because I do not want always debug rtems in the bsp. > > > > > > small...@aliyun.com > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: build: i386/pc686/appstart.o is created more than once
On 15/09/2020 15:21, Sebastian Huber wrote: Hello, please have a look at: https://devel.rtems.org/ticket/4079 I have no idea how this can be done in waf. Thomas Nagy helped me to fix this issue. I would have probably never found this solution myself: https://git.rtems.org/rtems/commit/?id=9979042a3a40ab5e59ff06dae0fc229cd8bb0cc9 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
I think that stating that "Due to a shared address space" RTEMS can't generate a "core dump" is wrong. For example, when a thread de-references a NULL pointer the rest of the application will be intact enough to create a "core dump". In general, when you're developing an application I don't think you want a "core dump", you want to have a debugger attached. In the field, if your multi-threaded application is functional and has a place to store a "core dump", I think it would be great to do so if possible. > On Sep 15, 2020, at 12:03 , Joel Sherrill wrote: > > > > On Tue, Sep 15, 2020 at 10:26 AM Gedare Bloom wrote: > No, there is no facility to generate a core dump. Due to shared > address space, once there is a fatal error you can't really trust > anything running in the target. You wouldn't necessarily want to try > writing to a mounted filesystem. > > You could probably set up a debugger to do something like this by > triggering it in the fatal exception handler. You'd need to make use > of whatever the debugger can do already though. You really can't rely > on the executing target. > > On the more popular architectures, if you get an exception, the BSP > will print out a lot of information. Included in that is usually the address > of the fault and register set. You can use the symbol table (from nm) > or addr2line to map that back to source code. Look at the generated > assembly and you can often tell what went wrong. > > Better is to attach a debugger and set a breakpoint on the exception > handler address and then poke around to see more details. > > --joel > > Gedare > > On Tue, Sep 15, 2020 at 4:58 AM small...@aliyun.com > wrote: > > > > I am developing applications in rtems 5.1. As we know, my application and > > rtems kernel are both in the same address space. > > So if my application access an invalid address or encounter other fatal > > errors, I want the kernel not just being hunging, but create a core dump > > file. > > This file contains the whole contents of memory and I could use a debuger > > to analyse the file to handle the bug. > > The question arise because I do not want always debug rtems in the bsp. > > > > > > small...@aliyun.com > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
On Tue, Sep 15, 2020 at 2:25 PM Peter Dufault wrote: > > I think that stating that "Due to a shared address space" RTEMS can't > generate a "core dump" is wrong. > > For example, when a thread de-references a NULL pointer the rest of the > application will be intact enough to create a "core dump". > That's fair. It depends on the fatal error though, and what has been corrupted already in memory. This is in general an unsafe thing to do without taking extra precautions, for example, by loading up a clean driver for your storage. Anyway, there isn't a general facility to do it. > In general, when you're developing an application I don't think you want a > "core dump", you want to have a debugger attached. > > In the field, if your multi-threaded application is functional and has a > place to store a "core dump", I think it would be great to do so if possible. > > > On Sep 15, 2020, at 12:03 , Joel Sherrill wrote: > > > > > > > > On Tue, Sep 15, 2020 at 10:26 AM Gedare Bloom wrote: > > No, there is no facility to generate a core dump. Due to shared > > address space, once there is a fatal error you can't really trust > > anything running in the target. You wouldn't necessarily want to try > > writing to a mounted filesystem. > > > > You could probably set up a debugger to do something like this by > > triggering it in the fatal exception handler. You'd need to make use > > of whatever the debugger can do already though. You really can't rely > > on the executing target. > > > > On the more popular architectures, if you get an exception, the BSP > > will print out a lot of information. Included in that is usually the address > > of the fault and register set. You can use the symbol table (from nm) > > or addr2line to map that back to source code. Look at the generated > > assembly and you can often tell what went wrong. > > > > Better is to attach a debugger and set a breakpoint on the exception > > handler address and then poke around to see more details. > > > > --joel > > > > Gedare > > > > On Tue, Sep 15, 2020 at 4:58 AM small...@aliyun.com > > wrote: > > > > > > I am developing applications in rtems 5.1. As we know, my application and > > > rtems kernel are both in the same address space. > > > So if my application access an invalid address or encounter other fatal > > > errors, I want the kernel not just being hunging, but create a core dump > > > file. > > > This file contains the whole contents of memory and I could use a debuger > > > to analyse the file to handle the bug. > > > The question arise because I do not want always debug rtems in the bsp. > > > > > > > > > small...@aliyun.com > > > ___ > > > devel mailing list > > > devel@rtems.org > > > http://lists.rtems.org/mailman/listinfo/devel > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > Peter > - > Peter Dufault > HD Associates, Inc. Software and System Engineering > > This email is delivered through the public internet using protocols subject > to interception and tampering. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] build: Add RELOCADDR to i386/pc386 options
On 15/9/20 9:33 pm, Sebastian Huber wrote:
> Module:rtems
> Branch:master
> Commit:d9d31b381c301d921dde7a691d8e27e2e39d68f3
> Changeset:
> http://git.rtems.org/rtems/commit/?id=d9d31b381c301d921dde7a691d8e27e2e39d68f3
>
> Author:Sebastian Huber
> Date: Tue Sep 15 13:29:36 2020 +0200
>
> build: Add RELOCADDR to i386/pc386 options
>
> Update #3818.
>
> ---
>
> spec/build/bsps/i386/pc386/grp.yml | 2 ++
> spec/build/bsps/i386/pc386/optrelocaddr.yml | 27 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/spec/build/bsps/i386/pc386/grp.yml
> b/spec/build/bsps/i386/pc386/grp.yml
> index 1127fc2..252b813 100644
> --- a/spec/build/bsps/i386/pc386/grp.yml
> +++ b/spec/build/bsps/i386/pc386/grp.yml
> @@ -24,6 +24,8 @@ links:
> - role: build-dependency
>uid: objvga
> - role: build-dependency
> + uid: optrelocaddr
> +- role: build-dependency
>uid: optvberm
> - role: build-dependency
>uid: objvgacir
> diff --git a/spec/build/bsps/i386/pc386/optrelocaddr.yml
> b/spec/build/bsps/i386/pc386/optrelocaddr.yml
> new file mode 100644
> index 000..e052383
> --- /dev/null
> +++ b/spec/build/bsps/i386/pc386/optrelocaddr.yml
> @@ -0,0 +1,27 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-integer: null
> +- assert-uint32: null
> +- env-assign: null
> +- set-value: -Wl,-Ttext,${RELOCADDR:#010x}
> +- substitute: null
> +- env-append: LDFLAGS
> +- env-append: PKGCONFIG_LDFLAGS
> +build-type: option
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +default: 1048576
Is hex supported? 0x10 is much friendlier and simpler to grep for.
Chris
> +default-by-variant: []
> +description: |
> + Set the value of RELOCADDR to the address where you want your image to
> load.
> + If you'll be using GRUB to load the images it will have to be >= 0x10
> + (1024K). If you are using NetBoot to load the images it can be
> + >= 0x1 (64K) AND <= 0x97C00 (607K) OR >= 0x10 (1024K). The memory
> + top is of course another limit. Make sure there is enough space before the
> + upper memory limits for the image and the memory allocated by it to fit.
> + Make sure the value you choose is aligned to 4 bytes.
> +enabled-by: true
> +format: '{:#010x}'
> +links: []
> +name: RELOCADDR
> +type: build
>
> ___
> vc mailing list
> v...@rtems.org
> http://lists.rtems.org/mailman/listinfo/vc
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
On 16/9/20 7:22 am, Gedare Bloom wrote: > On Tue, Sep 15, 2020 at 2:25 PM Peter Dufault wrote: >> >> I think that stating that "Due to a shared address space" RTEMS can't >> generate a "core dump" is wrong. >> >> For example, when a thread de-references a NULL pointer the rest of the >> application will be intact enough to create a "core dump". >> > That's fair. It depends on the fatal error though, and what has been > corrupted already in memory. This is in general an unsafe thing to do > without taking extra precautions, for example, by loading up a clean > driver for your storage. A NULL pointer access on ARM is caught by libdebugger and you are placed on the instruction that faulted. Backtrace works on the faulting task and all the other tasks can be inspected including their backtrace. The interesting part when it happens a number of other tasks including libbsd are running happily. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
On 15/9/20 8:58 pm, small...@aliyun.com wrote:
> I am developing applications in rtems 5.1. As we know, my application and
> rtems
> kernel are both in the same address space.
> So if my application access an invalid address or encounter other fatal
> errors,
> I want the kernel not just being hunging, but create a core dump file.
> This file contains the whole contents of memory and I could use a debuger to
> analyse the file to handle the bug.
> The question arise because I do not want always debug rtems in the bsp.
This is an interesting question. For production units I think capturing and
reporting an error is important but a full core is not worth the effort.
Core images can be saved with a single address space OS. I remember Cisco's
single address space OS for routers from 20 years ago could capture a complete
core that could be loaded by gdb. Those devices had a Compact flash card
installed to capture the core and I suppose their users did not mind the wait
while the core was saved.
As others have explained capturing the full address space and saving it so gdb
could be taught to load it is difficult. You need to put aside some memory to
construct the core image as you save it and you need to have small stand alone
drivers and what ever else to get the image off the target and saved. RTEMS
cannot be used. Where this approach gets hard is when you start to consider
hardware failure type issues.
My preferred solution is to add a small storage area away from the RTEMS memory
map called the Run Time Error (RTE) store. This is a piece of RAM that can
survive a reset or reboot and is not part of the RTEMS memory map. Internal SoC
memory can often be enough. The memory cannot be cleared or corrupted during
reset. The struct is something like:
typedef struct
{
uint32_t type;/* The type of error in this trace buffer. */
uint32_t count; /* The number of times we have had an error. */
uint64_t uptime; /* The period of time we have been up. */
union
{
error_trace_fatal fatal; /* A fatal error. */
error_trace_assert assert; /* An assert error. */
error_trace_error error; /* An error code. */
} error;
uint32_t crc; /* Checksum */
} error_trace;
You provide a struct for a fatal error, an assert or an error. It is a matter of
hooking the error handlers and saving the data. The fatal error is something
like:
typedef struct
{
rtems_fatal_source source;
uint32_tinternal;
rtems_fatal_codecode;
CPU_Exception_frame frame;
uint32_tstack[ET_STACK_SIZE];
} error_trace_fatal;
Catch the fatal error handler and fill in the fields including the crc then
reset the board. Limit the code you call before reset.
When RTEMS starts get your application to check the RTE and if the checksum is
valid check the error count. If the error count is not zero you have captured an
error. You now have a working RTEMS that can be used to process and save the
error. I have production systems that save errors to a JFFS2 disk and a web
interface can be used to download it. I also have systems that send the data to
a syslog type server when the devices are networked. In those systems it is
really important to capture _every_ reset.
Finding the error in the code is a matter of getting the PC address and the ELF
executable image with the DWARF debug information and using `objdump -d
--source`. Disassemble the exe with source and search for the PC address. The
report points to the location and the dumped registers will help you see what
the issue is. Most of the time the issue can be found or investigated further
and resolved but sometimes it cannot be found directly. In those cases you need
to stress the system in a lab to expose the crash and then investigate. The key
information is the crash happened and where.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 16/9/20 2:03 am, Kinsey Moore wrote: > I had assumed that the old build system would be removed when the new build > system got added, but that obviously didn't happen. Will it eventually be > removed after a transition period is over or will they both exist and be > maintained going forward? I do not expect to see any changes to the autoconf and automake build system. The autotools build system will be removed once we are happy things have been checked and are OK _and_ the supporting ecosystem tools know how to build the kernel with waf. The 6.1 release will not have a configure script or Makefile at the top level. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
You are right. Anything in the target could not been used to generate a core dump. In Linux kernel, there is a mini kernel outside the running kernel. When the running kernel crash, it will trigger the mini kernel to run. The mini kernel will analyse the memory of the crashed kernel and generate a core dump file. Then, I will use the crash cmd to analyse the core dump and find the reason of this crash. Is it possible to reserve some memory for a mini rtems kernel. This memory can not be used by the normal kernel. Once the normal kernel crashed, the mini kernel can generate a core dump of the normal kernel. small...@aliyun.com From: Gedare Bloom Date: 2020-09-15 23:26 To: small...@aliyun.com CC: devel Subject: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors? No, there is no facility to generate a core dump. Due to shared address space, once there is a fatal error you can't really trust anything running in the target. You wouldn't necessarily want to try writing to a mounted filesystem. You could probably set up a debugger to do something like this by triggering it in the fatal exception handler. You'd need to make use of whatever the debugger can do already though. You really can't rely on the executing target. Gedare On Tue, Sep 15, 2020 at 4:58 AM small...@aliyun.com wrote: > > I am developing applications in rtems 5.1. As we know, my application and > rtems kernel are both in the same address space. > So if my application access an invalid address or encounter other fatal > errors, I want the kernel not just being hunging, but create a core dump file. > This file contains the whole contents of memory and I could use a debuger to > analyse the file to handle the bug. > The question arise because I do not want always debug rtems in the bsp. > > > small...@aliyun.com > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 15/9/20 5:36 pm, Sebastian Huber wrote: > On 15/09/2020 09:32, Karel Gardas wrote: > >> On 9/15/20 9:28 AM, Sebastian Huber wrote: >>> Maybe it is more practical if we add a table to a wiki page in which >>> everyone can add the BSPs which were tested with the new build system. >> I think this would be fantastic to have. > An alternative would be to add it to the ticket as a comment. I can add a > table > to the ticket description and update the table based on the comments. A ticket is hard to account for the BSPs once checked. I have created a BSP checklist table with some columns I think are useful. I hope this is OK: https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 6-freebsd-12 3/4] build: Separate the kernel and user land include paths
On 16/9/20 12:48 am, Joel Sherrill wrote: > On Mon, Sep 14, 2020 at 9:33 PM mailto:chr...@rtems.org>> > wrote: > > From: Chris Johns mailto:chr...@rtems.org>> > > - Provide support for separate user and kernel include paths in > libbsd.py. > > - Update all added files with a suitable context to build them > with. Supported contexts are `kernel` and `user`. > > - Kernel source use the kernel, CPU, and build header paths in > this order. > > - User source use the user, kernel, CPU and build header paths > in this order. The FreeBSD /usr/include tree has some kernel > header files installed as well as user land header files. This > complicates the separation as some kernel header files are not > visible to user land code while other are. This is handled by > appeanding the kernel header paths to the user header paths so > > > ^^^ appending Thanks. > Otherwise, I am just asking does Python code need to pass. pylint > and yapf are mentioned in this thread but > https://books.agiliq.com/projects/essential-python-tools/en/latest/linters.html > has a list of tools and claims that pycodelint matches pep8. I thought we > were trying to follow pep8. I thought yapf did pep8. I followed the 6.5.2 guide lines. > It also mentions pyflake which sounds useful. > > What is the recommended set of tools to pass and with what settings? > > I know we aren't completely passing on all Python code but what's the > objective from a tool checking viewpoint. This is existing code and I did not think we needed to pass pylint and yapf to make changes. I did pass the code through yapf as a separate patch to help the process. See 1/4. Pylint is more work than I have time avalable to do on this code. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
Thanks very much for you reply. I get many useful information from your
suggestion.
Our BSP has a 8MB memory for rtems and a 32MB flash device. So it may not spend
too much time for dumping the core.
The question is that our application running with rtems is very complex. There
are several threads and many async processes.
When the fatal error happened, it is possible that the backtrace of current
thread is not enough.
We need analyse other data structures to debug, such as all items in a queue or
some global variable.
What's more, when our product sold to consumer and some bugs trigger a crash.
We could not connect to user's environment to debug.
So, it will be a better option if a core dump is generated.
However, if the core dump policy is not possible, the method you provided is
feasible.
I will study it and check how it will be integrated to our system.
small...@aliyun.com
From: Chris Johns
Date: 2020-09-16 08:33
To: small...@aliyun.com; devel
Subject: Re: does rtems 5.1 support create a core dump file when accessing a
invalid address or other fatal errors?
On 15/9/20 8:58 pm, small...@aliyun.com wrote:
> I am developing applications in rtems 5.1. As we know, my application and
> rtems
> kernel are both in the same address space.
> So if my application access an invalid address or encounter other fatal
> errors,
> I want the kernel not just being hunging, but create a core dump file.
> This file contains the whole contents of memory and I could use a debuger to
> analyse the file to handle the bug.
> The question arise because I do not want always debug rtems in the bsp.
This is an interesting question. For production units I think capturing and
reporting an error is important but a full core is not worth the effort.
Core images can be saved with a single address space OS. I remember Cisco's
single address space OS for routers from 20 years ago could capture a complete
core that could be loaded by gdb. Those devices had a Compact flash card
installed to capture the core and I suppose their users did not mind the wait
while the core was saved.
As others have explained capturing the full address space and saving it so gdb
could be taught to load it is difficult. You need to put aside some memory to
construct the core image as you save it and you need to have small stand alone
drivers and what ever else to get the image off the target and saved. RTEMS
cannot be used. Where this approach gets hard is when you start to consider
hardware failure type issues.
My preferred solution is to add a small storage area away from the RTEMS memory
map called the Run Time Error (RTE) store. This is a piece of RAM that can
survive a reset or reboot and is not part of the RTEMS memory map. Internal SoC
memory can often be enough. The memory cannot be cleared or corrupted during
reset. The struct is something like:
typedef struct
{
uint32_t type;/* The type of error in this trace buffer. */
uint32_t count; /* The number of times we have had an error. */
uint64_t uptime; /* The period of time we have been up. */
union
{
error_trace_fatal fatal; /* A fatal error. */
error_trace_assert assert; /* An assert error. */
error_trace_error error; /* An error code. */
} error;
uint32_t crc; /* Checksum */
} error_trace;
You provide a struct for a fatal error, an assert or an error. It is a matter of
hooking the error handlers and saving the data. The fatal error is something
like:
typedef struct
{
rtems_fatal_source source;
uint32_tinternal;
rtems_fatal_codecode;
CPU_Exception_frame frame;
uint32_tstack[ET_STACK_SIZE];
} error_trace_fatal;
Catch the fatal error handler and fill in the fields including the crc then
reset the board. Limit the code you call before reset.
When RTEMS starts get your application to check the RTE and if the checksum is
valid check the error count. If the error count is not zero you have captured an
error. You now have a working RTEMS that can be used to process and save the
error. I have production systems that save errors to a JFFS2 disk and a web
interface can be used to download it. I also have systems that send the data to
a syslog type server when the devices are networked. In those systems it is
really important to capture _every_ reset.
Finding the error in the code is a matter of getting the PC address and the ELF
executable image with the DWARF debug information and using `objdump -d
--source`. Disassemble the exe with source and search for the PC address. The
report points to the location and the dumped registers will help you see what
the issue is. Most of the time the issue can be found or investigated further
and resolved but sometimes it cannot be found directly. In those cases you need
to stress the system in a lab to expose the crash and then investigate. The key
information is the crash happened and where.
Chris
___
devel maili
Re: does rtems 5.1 support create a core dump file when accessing a invalid address or other fatal errors?
On 16/9/20 11:45 am, small...@aliyun.com wrote: > Thanks very much for you reply. I get many useful information from your > suggestion. No problem. > Our BSP has a 8MB memory for rtems and a 32MB flash device. So it may not > spend > too much time for dumping the core. > The question is that our application running with rtems is very complex. There > are several threads and many async processes. > When the fatal error happened, it is possible that the backtrace of current > thread is not enough. > We need analyse other data structures to debug, such as all items in a queue > or > some global variable. That is fine. Complex applications are what we want to hear about. :) > What's more, when our product sold to consumer and some bugs trigger a crash. > We > could not connect to user's environment to debug. > So, it will be a better option if a core dump is generated. You need to capture something but do you need all the memory. > However, if the core dump policy is not possible, the method you provided is > feasible. A core dump might be possible, it is just not currently available. A workable core would be hard and I suspect would have a number of limitations and it would take a lot of core developer time to do. Apart of the target capture side we would need to teach GDB to understand the core image and RTEMS threads so you could switch threads and provide a backtrace. That alone is a sizeable piece of work. > I will study it and check how it will be integrated to our system. I would select the important data you need to know and then add it to the RTE struct. What you capture is not limited to what RTEMS provides. You are free to instrument your application and capture that data on a crash. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On Tue, Sep 15, 2020 at 7:16 PM Chris Johns wrote: > > On 15/9/20 5:36 pm, Sebastian Huber wrote: > > On 15/09/2020 09:32, Karel Gardas wrote: > > > >> On 9/15/20 9:28 AM, Sebastian Huber wrote: > >>> Maybe it is more practical if we add a table to a wiki page in which > >>> everyone can add the BSPs which were tested with the new build system. > >> I think this would be fantastic to have. > > An alternative would be to add it to the ticket as a comment. I can add a > > table > > to the ticket description and update the table based on the comments. > > A ticket is hard to account for the BSPs once checked. I have created a BSP > checklist table with some columns I think are useful. I hope this is OK: > > https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist > Can you add a brief explanation of each column? I think I know, but I don't want to assume. > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 16/9/20 12:21 pm, Gedare Bloom wrote: > Can you add a brief explanation of each column? I think I know, but I > don't want to assume. Yes that is a good idea. I will do it now. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems_task_create_from_config() Name?
On 15/9/20 6:55 pm, Sebastian Huber wrote: > On 14/09/2020 06:52, Sebastian Huber wrote: > >>> >>> They are created using the words from your sentence above :) >>> My favorite is still rtems_task_build(). >>> >>> Not mine. Do you create, build then start? I think it needs create and it >>> lacks >>> the storage bit. >> >> Maybe we should use a synonym of "create" (build is not a synonym of create) >> such as "make": >> >> rtems_task_make() >> >> rtems_message_queue_make() > > With respect to the directive name, what about the "make" variant? I think > this > avoids a potential create, build then start confusion. We have create then > start, or make then start. I think this idea. > Maybe another synonym of create like produce, fabricate, construct, forge, > ...? rtems_task_construct() ? You create a task including its resources and you construct a task from the provided resources. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems_task_create_from_config() Name?
On Tue, Sep 15, 2020, 10:35 PM Chris Johns wrote: > On 15/9/20 6:55 pm, Sebastian Huber wrote: > > On 14/09/2020 06:52, Sebastian Huber wrote: > > > >>> > >>> They are created using the words from your sentence above :) > >>> > My favorite is still rtems_task_build(). > >>> > >>> Not mine. Do you create, build then start? I think it needs create and > it lacks > >>> the storage bit. > >> > >> Maybe we should use a synonym of "create" (build is not a synonym of > create) > >> such as "make": > >> > >> rtems_task_make() > >> > >> rtems_message_queue_make() > > > > With respect to the directive name, what about the "make" variant? I > think this > > avoids a potential create, build then start confusion. We have create > then > > start, or make then start. > > I think this idea. > > > Maybe another synonym of create like produce, fabricate, construct, > forge, ...? > > rtems_task_construct() ? > I kind of like this but this may be because the FACE Life Cycle has construction, initialisation, configuration, finalization, and destruction. This really is a construction phase operation. > > You create a task including its resources and you construct a task from the > provided resources. > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Psxtest: Fix String truncation warning
On 15/9/20 7:04 pm, Aschref Ben-Thabet wrote: > From: Aschref Ben Thabet > > Replace strncpy() with strdup() to silence this warning since it tries > to allocate enough memory to hold the old string (plus a '\0' character > to mark the end of the string). > --- > testsuites/psxtests/psxndbm01/init.c | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git a/testsuites/psxtests/psxndbm01/init.c > b/testsuites/psxtests/psxndbm01/init.c > index a13afa7315..ddcc1b5bf6 100644 > --- a/testsuites/psxtests/psxndbm01/init.c > +++ b/testsuites/psxtests/psxndbm01/init.c > @@ -217,14 +217,9 @@ rtems_task Init(rtems_task_argument ignored) >rtems_test_assert( strcmp( (const char*)get_phone_no.dptr, PHONE_NO2 ) == > 0 ); > >puts( "Fetch non-existing record and confirm error." ); > - test_strings = (char*)malloc(6); > - strncpy( test_strings, "Hello", 5 ); > - > - test_strings[5] = '\0'; > + test_strings = strdup( "Hello" ); > > /* The data pointed by test_string is now pointed by key.dptr */ > - key.dptr = test_strings; > - key.dsize = sizeof( test_strings ); >get_phone_no = dbm_fetch( db, key ); Is key now uninitialised as the assignment above have been removed? >rtems_test_assert( get_phone_no.dptr == NULL ); >dbm_close( db ); > @@ -237,10 +232,10 @@ rtems_task Init(rtems_task_argument ignored) >db = dbm_open( DB_NAME, O_RDWR, S_IRWXU ); >rtems_test_assert( db != NULL ); > > - puts( "Delete non-existing record and confirm error." ); > + /* puts( "Delete non-existing record and confirm error." ); >rtems_test_assert( dbm_delete( db, key ) != 0 ); >free( test_strings ); > - rtems_test_assert( count_no_of_records( db ) == 2); > + rtems_test_assert( count_no_of_records( db ) == 2);*/ Why is this being commented out? Does this leaking the memory from strdup? What about moving test_strings to the file scope and making it be: char test_strings[PATH_MAX]; Then remove the pair of malloc and free calls. Chris > >puts( "Delete existing record and " > "confirm that total number of records is successful 1." ); > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libmisc/capture: Fix unaligned pointer value warning
On 15/9/20 7:04 pm, Aschref Ben-Thabet wrote: > From: Aschref Ben Thabet > > Change the function ctrace_task_name_add() to take the variable name as > a value instead a pointer. > It avoids the warning and solve the issue. What warning? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning
On 15/9/20 7:06 pm, Aschref Ben-Thabet wrote:
> From: Aschref Ben Thabet
>
> Taking care of the size of buffer to be copied and replace the unsafe
> snprintf() with memcpy().
> The reason why we get a warning on sprintf() is because memcpy() has a
> length parameter that limits how much memory you copy.
> For memcpy(), the input has to be terminated with a \0. If not, it will
> continue out of bounds.
> ---
> cpukit/mghttpd/mongoose.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/mghttpd/mongoose.c b/cpukit/mghttpd/mongoose.c
> index fb2bce7471..6db0bdb58e 100644
> --- a/cpukit/mghttpd/mongoose.c
> +++ b/cpukit/mghttpd/mongoose.c
> @@ -251,7 +251,7 @@ typedef struct DIR {
> #define INT64_FMT PRId64
> typedef int SOCKET;
> #define WINCDECL
> -
> +#define MIN(a, b)((a) < (b) ? (a) : (b))
> #endif // End of Windows and UNIX specific includes
>
> #ifndef HAVE_POLL
> @@ -1916,12 +1916,24 @@ static void convert_uri_to_file_name(struct
> mg_connection *conn, char *buf,
>// we can only do this if the browser declares support
>if ((accept_encoding = mg_get_header(conn, "Accept-Encoding")) != NULL) {
> if (strstr(accept_encoding,"gzip") != NULL) {
> - snprintf(gz_path, sizeof(gz_path), "%s.gz", buf);
> - if (mg_stat(conn, gz_path, filep)) {
> -filep->gzipped = 1;
> -return;
> + memcpy(gz_path, buf, MIN(strlen(buf) + 1, sizeof(gz_path)));
> + if (strlen(buf) > sizeof(gz_path) - 1)
> + strlcpy(gz_path + strlen(gz_path), ".gz", sizeof(gz_path) -
> strlen(gz_path));
> + /* else //to be reviewed /
Huh?
> + {
> + //memory allocation for gz.path with buf_size + .gz
We use C comments.
> + mount_path = malloc(strlen(buf) + 1 + sizeof(gz_path);
> + if (mount_path != NULL))
> +strlcpy(mount_path, ".gz", sizeof(mount_path));
> + }
> + snprintf(gz_path, sizeof(gz_path), "%s.gz", buf*)
> +*/
Sorry I am not reviewing these changes any more.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning
On 16/09/2020 05:59, Chris Johns wrote: + mount_path = malloc(strlen(buf) + 1 + sizeof(gz_path); + if (mount_path != NULL)) +strlcpy(mount_path, ".gz", sizeof(mount_path)); + } + snprintf(gz_path, sizeof(gz_path), "%s.gz", buf*) +*/ Sorry I am not reviewing these changes any more. Sorry Chris, this is my fault. I was not clear enough to communicate that this patch set should first go through an internal review before we send it to the mailing list. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/mghttpd/mongoose: Fix format truncation warning
On 16/9/20 2:36 pm, Sebastian Huber wrote: > On 16/09/2020 05:59, Chris Johns wrote: > >>> + mount_path = malloc(strlen(buf) + 1 + sizeof(gz_path); >>> + if (mount_path != NULL)) >>> + strlcpy(mount_path, ".gz", sizeof(mount_path)); >>> + } >>> + snprintf(gz_path, sizeof(gz_path), "%s.gz", buf*) >>> +*/ >> Sorry I am not reviewing these changes any more. > Sorry Chris, this is my fault. I was not clear enough to communicate that this > patch set should first go through an internal review before we send it to the > mailing list. All good. I wanted the record to show what happened to the patches. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] build: Add RELOCADDR to i386/pc386 options
On 16/09/2020 01:26, Chris Johns wrote: +default: 1048576 Is hex supported? 0x10 is much friendlier and simpler to grep for. It would be difficult to add support for this. The YAML parser can read hex number, however, the default YAML formatter writes all integers as decimals. If you want hex numbers, then you need a hand crafted formatter. In ./waf bsp_defaults you get a hex number (see the format attribute). ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: New build system ready for testing
On 9/16/20 3:16 AM, Chris Johns wrote: > On 15/9/20 5:36 pm, Sebastian Huber wrote: >> On 15/09/2020 09:32, Karel Gardas wrote: >> >>> On 9/15/20 9:28 AM, Sebastian Huber wrote: Maybe it is more practical if we add a table to a wiki page in which everyone can add the BSPs which were tested with the new build system. >>> I think this would be fantastic to have. >> An alternative would be to add it to the ticket as a comment. I can add a >> table >> to the ticket description and update the table based on the comments. > > A ticket is hard to account for the BSPs once checked. I have created a BSP > checklist table with some columns I think are useful. I hope this is OK: > > https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist Looks great, but on submit attempt I've been welcome by "Akismet says content is spam" and I guess I solved math exercise well... Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
