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,
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
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
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
___
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).
> ---
>
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.
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
>>>
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
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
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
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
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
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
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
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
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
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
>>
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
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
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
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:
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.
>
>
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
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
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
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
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
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
> 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
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
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,
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.
---
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
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
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
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
+++
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
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
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
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
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
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
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
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
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
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"
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
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
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
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
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
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
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
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
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
On 15/9/20 4:31 pm, Sebastian Huber wrote:
> On 15/09/2020 00:46, Chris Johns wrote:
>
>> On 15/9/20 1:18 am, Sebastian Huber wrote:
>>> Hello Christian,
>>>
>>> On 14/09/2020 14:23, Christian Mauderer wrote:
Hello Sebastian,
I get a linker error when I try to build libbsd for BBB
Thanks, Sebastian, LGTM.
On Mon, 14 Sep 2020 at 14:01, Joel Sherrill wrote:
>
> Looks good. Reasonable and safer.
>
> On Mon, Sep 14, 2020 at 12:10 AM Sebastian Huber
> wrote:
>>
>> Use a far jump to avoid errors like this:
>>
>> relocation truncated to fit: R_RISCV_JAL against symbol
On 15/09/2020 00:46, Chris Johns wrote:
On 15/9/20 1:18 am, Sebastian Huber wrote:
Hello Christian,
On 14/09/2020 14:23, Christian Mauderer wrote:
Hello Sebastian,
I get a linker error when I try to build libbsd for BBB (with a buildset that
builds everything but netipsec):
-
58 matches
Mail list logo
