ci: shippable: troubleshoot xtest issue #1
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jforissier
force-pushed
the
shippable-xtest
branch
from
5832c4e
to
f7676d7
Compare
There is a bug in the step that prepares a source tree to build and run OP-TEE with QEMU, at the end of the CI script. The idea is, clone the current project forest using the repo tool, then remove optee_os and replace it with a symbolic link to the one that has been checked out in the CI infrastructure. So that, we are effectively testing the desired pull request or branch. The problem is, the symlink is not removed at the end of the script, so it ends up being cached and restored with the next build. The repo sync command follows the symlink and overwrites the "good" optee_os with the current master branch and at this point we're doomed. Fix that by making sure there is no optee_os symlink leftover from the cache. Signed-off-by: Jerome Forissier <[email protected]>
jforissier
force-pushed
the
shippable-xtest
branch
from
12c0da7
to
ea19ec2
Compare
jforissier
added a commit
that referenced
this pull request
Oct 12, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Oct 16, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Oct 16, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Oct 16, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Oct 17, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Oct 17, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 7, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Joakim Bech <[email protected]>
Reviewed-by: Etienne Carriere <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 8, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Joakim Bech <[email protected]>
Reviewed-by: Etienne Carriere <[email protected]>
Acked-by: Jens Wiklander <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 12, 2018
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Joakim Bech <[email protected]>
Reviewed-by: Etienne Carriere <[email protected]>
Acked-by: Jens Wiklander <[email protected]>
jforissier
added a commit
that referenced
this pull request
Apr 11, 2019
The memory tests in core_self_tests.c call the malloc()/calloc() API
without doing anything meaningful with the output. It turns out that a
clever compiler (read: Clang) will detect this and aggressively
optimize the code, to the point that a call to calloc() is removed
entirely. Here is a reduced test case for the record:
$ cat test.c
#include <stdlib.h>
int main(int argc, char *argv[])
{
return calloc(1000000, 1) ? 1 : 0;
}
$ clang --target=arm-linux-gnueabihf -Os -c test.c
$ llvm-objdump -d test.o
test.o: file format ELF32-arm-little
Disassembly of section .text:
0000000000000000 main:
0: 01 00 a0 e3 mov r0, #1
4: 1e ff 2f e1 bx lr
No call to calloc() in the generated code! As strange as it may seem,
this is reportedly a valid bahavior for the compiler [1].
This optimization is obviously not wanted for the test that tries to
check that allocation of a very large buffer fails in OP-TEE.
This commit adds the -fno-builtins flag to the compiler command for that
particular source file, thus preventing the optimization and making the
test pass.
Link: [1] https://bugs.llvm.org/show_bug.cgi?id=37304
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
May 15, 2019
The memory tests in core_self_tests.c call the malloc()/calloc() API
without doing anything meaningful with the output. It turns out that a
clever compiler (read: Clang) will detect this and aggressively
optimize the code, to the point that a call to calloc() is removed
entirely. Here is a reduced test case for the record:
$ cat test.c
#include <stdlib.h>
int main(int argc, char *argv[])
{
return calloc(1000000, 1) ? 1 : 0;
}
$ clang --target=arm-linux-gnueabihf -Os -c test.c
$ llvm-objdump -d test.o
test.o: file format ELF32-arm-little
Disassembly of section .text:
0000000000000000 main:
0: 01 00 a0 e3 mov r0, #1
4: 1e ff 2f e1 bx lr
No call to calloc() in the generated code! As strange as it may seem,
this is reportedly a valid bahavior for the compiler [1].
This optimization is obviously not wanted for the test that tries to
check that allocation of a very large buffer fails in OP-TEE.
This commit adds the -fno-builtins flag to the compiler command for that
particular source file, thus preventing the optimization and making the
test pass.
Link: [1] https://bugs.llvm.org/show_bug.cgi?id=37304
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Jul 3, 2019
The memory tests in core_self_tests.c call the malloc()/calloc() API
without doing anything meaningful with the output. It turns out that a
clever compiler (read: Clang) will detect this and aggressively
optimize the code, to the point that a call to calloc() is removed
entirely. Here is a reduced test case for the record:
$ cat test.c
#include <stdlib.h>
int main(int argc, char *argv[])
{
return calloc(1000000, 1) ? 1 : 0;
}
$ clang --target=arm-linux-gnueabihf -Os -c test.c
$ llvm-objdump -d test.o
test.o: file format ELF32-arm-little
Disassembly of section .text:
0000000000000000 main:
0: 01 00 a0 e3 mov r0, #1
4: 1e ff 2f e1 bx lr
No call to calloc() in the generated code! As strange as it may seem,
this is reportedly a valid bahavior for the compiler [1].
This optimization is obviously not wanted for the test that tries to
check that allocation of a very large buffer fails in OP-TEE.
This commit adds the -fno-builtins flag to the compiler command for that
particular source file, thus preventing the optimization and making the
test pass.
Link: [1] https://bugs.llvm.org/show_bug.cgi?id=37304
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Jul 5, 2019
The memory tests in core_self_tests.c call the malloc()/calloc() API
without doing anything meaningful with the output. It turns out that a
clever compiler (read: Clang) will detect this and aggressively
optimize the code, to the point that a call to calloc() is removed
entirely. Here is a reduced test case for the record:
$ cat test.c
#include <stdlib.h>
int main(int argc, char *argv[])
{
return calloc(1000000, 1) ? 1 : 0;
}
$ clang --target=arm-linux-gnueabihf -Os -c test.c
$ llvm-objdump -d test.o
test.o: file format ELF32-arm-little
Disassembly of section .text:
0000000000000000 main:
0: 01 00 a0 e3 mov r0, #1
4: 1e ff 2f e1 bx lr
No call to calloc() in the generated code! As strange as it may seem,
this is reportedly a valid bahavior for the compiler [1].
This optimization is obviously not wanted for the test that tries to
check that allocation of a very large buffer fails in OP-TEE.
This commit adds the -fno-builtins flag to the compiler command for that
particular source file, thus preventing the optimization and making the
test pass.
Link: [1] https://bugs.llvm.org/show_bug.cgi?id=37304
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Jul 8, 2019
The memory tests in core_self_tests.c call the malloc()/calloc() API
without doing anything meaningful with the output. It turns out that a
clever compiler (read: Clang) will detect this and aggressively
optimize the code, to the point that a call to calloc() is removed
entirely. Here is a reduced test case for the record:
$ cat test.c
#include <stdlib.h>
int main(int argc, char *argv[])
{
return calloc(1000000, 1) ? 1 : 0;
}
$ clang --target=arm-linux-gnueabihf -Os -c test.c
$ llvm-objdump -d test.o
test.o: file format ELF32-arm-little
Disassembly of section .text:
0000000000000000 main:
0: 01 00 a0 e3 mov r0, #1
4: 1e ff 2f e1 bx lr
No call to calloc() in the generated code! As strange as it may seem,
this is reportedly a valid behavior for the compiler [1].
This optimization is obviously not wanted for the test that tries to
check that allocation of a very large buffer fails in OP-TEE.
This commit adds the -fno-builtins flag to the compiler command for that
particular source file, thus preventing the optimization and making the
test pass.
Link: [1] https://bugs.llvm.org/show_bug.cgi?id=37304
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Jul 9, 2019
The memory tests in core_self_tests.c call the malloc()/calloc() API
without doing anything meaningful with the output. It turns out that a
clever compiler (read: Clang) will detect this and aggressively
optimize the code, to the point that a call to calloc() is removed
entirely. Here is a reduced test case for the record:
$ cat test.c
#include <stdlib.h>
int main(int argc, char *argv[])
{
return calloc(1000000, 1) ? 1 : 0;
}
$ clang --target=arm-linux-gnueabihf -Os -c test.c
$ llvm-objdump -d test.o
test.o: file format ELF32-arm-little
Disassembly of section .text:
0000000000000000 main:
0: 01 00 a0 e3 mov r0, #1
4: 1e ff 2f e1 bx lr
No call to calloc() in the generated code! As strange as it may seem,
this is reportedly a valid behavior for the compiler [1].
This optimization is obviously not wanted for the test that tries to
check that allocation of a very large buffer fails in OP-TEE.
This commit adds the -fno-builtins flag to the compiler command for that
particular source file, thus preventing the optimization and making the
test pass.
Link: [1] https://bugs.llvm.org/show_bug.cgi?id=37304
Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Jul 10, 2019
The memory tests in core_self_tests.c call the malloc()/calloc() API
without doing anything meaningful with the output. It turns out that a
clever compiler (read: Clang) will detect this and aggressively
optimize the code, to the point that a call to calloc() is removed
entirely. Here is a reduced test case for the record:
$ cat test.c
#include <stdlib.h>
int main(int argc, char *argv[])
{
return calloc(1000000, 1) ? 1 : 0;
}
$ clang --target=arm-linux-gnueabihf -Os -c test.c
$ llvm-objdump -d test.o
test.o: file format ELF32-arm-little
Disassembly of section .text:
0000000000000000 main:
0: 01 00 a0 e3 mov r0, #1
4: 1e ff 2f e1 bx lr
No call to calloc() in the generated code! As strange as it may seem,
this is reportedly a valid behavior for the compiler [1].
This optimization is obviously not wanted for the test that tries to
check that allocation of a very large buffer fails in OP-TEE.
This commit adds the -fno-builtins flag to the compiler command for that
particular source file, thus preventing the optimization and making the
test pass.
Link: [1] https://bugs.llvm.org/show_bug.cgi?id=37304
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Jens Wiklander <[email protected]>
jforissier
added a commit
that referenced
this pull request
Jul 10, 2019
The memory tests in core_self_tests.c call the malloc()/calloc() API
without doing anything meaningful with the output. It turns out that a
clever compiler (read: Clang) will detect this and aggressively
optimize the code, to the point that a call to calloc() is removed
entirely. Here is a reduced test case for the record:
$ cat test.c
#include <stdlib.h>
int main(int argc, char *argv[])
{
return calloc(1000000, 1) ? 1 : 0;
}
$ clang --target=arm-linux-gnueabihf -Os -c test.c
$ llvm-objdump -d test.o
test.o: file format ELF32-arm-little
Disassembly of section .text:
0000000000000000 main:
0: 01 00 a0 e3 mov r0, #1
4: 1e ff 2f e1 bx lr
No call to calloc() in the generated code! As strange as it may seem,
this is reportedly a valid behavior for the compiler [1].
This optimization is obviously not wanted for the test that tries to
check that allocation of a very large buffer fails in OP-TEE.
This commit adds the -fno-builtins flag to the compiler command for that
particular source file, thus preventing the optimization and making the
test pass.
Link: [1] https://bugs.llvm.org/show_bug.cgi?id=37304
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Jens Wiklander <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 5, 2019
When CFG_FTRACE_SUPPORT=y, thumb mode is not supported. Therefore we have to make sure that code that uses ftrace is built with -marm. That flag is currently missing for assembler files. Add it. Fixes a crash in the setjmp()/longjmp() test of xtest 1006 when GCC 6.2 is used to build the user space libutils.a (more precisely, lib/libutils/isoc/arch/arm/setjmp_a32.S): E/TC:? 0 User TA prefetch-abort at address 0x0 (translation fault) E/TC:? 0 fsr 0x00000005 ttbr0 0x0e19206a ttbr1 0x0e18806a cidr 0x2 E/TC:? 0 cpu #1 cpsr 0x60000110 E/TC:? 0 r0 0x00000000 r4 0x00115780 r8 0x00000000 r12 0x00115658 E/TC:? 0 r1 0x00000001 r5 0x0011fb8c r9 0x00000000 sp 0x001156a0 E/TC:? 0 r2 0x00000000 r6 0x60000110 r10 0x00000000 lr 0x00000000 E/TC:? 0 r3 0x00000000 r7 0x00000000 r11 0x001156bc pc 0x00000000 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: arm E/LD: region 0: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x00104000 pa 0x0e302000 size 0x00a000 flags r-xs (ldelf) E/LD: region 2: va 0x0010e000 pa 0x0e30c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x0010f000 pa 0x0e30d000 size 0x003000 flags rw-s (ldelf) E/LD: region 4: va 0x00112000 pa 0x0e310000 size 0x001000 flags r--s E/LD: region 5: va 0x00113000 pa 0x0e444000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x0011b000 pa 0x00001000 size 0x024000 flags r-xs [0] E/LD: region 7: va 0x0013f000 pa 0x00025000 size 0x10f000 flags rw-s [0] E/LD: region 8: va 0x00266000 pa 0x00000000 size 0x003000 flags r-xs [1] E/LD: region 9: va 0x00269000 pa 0x00002000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x00300000 pa 0x40a67570 size 0x001000 flags rw-- (param) E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x0011b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x00266000 E/LD: Call stack: E/LD: 0x00000000 Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 5, 2019
When CFG_FTRACE_SUPPORT=y, thumb mode should not be used in TA code, because the ftrace code assumes arm instructions. Therefore we have to pass the -marm flag to the compiler and assembler. This is correctrly done for the C compiler but not for the assembler -- fix that. The same fix applies for assembler files in the TEE core when CFG_SYSCALL_FTRACE=y. Fixes a crash in the setjmp()/longjmp() test of xtest 1006 when GCC 6.2 is used to build the user space libutils.a (more precisely: lib/libutils/isoc/arch/arm/setjmp_a32.S): E/TC:? 0 User TA prefetch-abort at address 0x0 (translation fault) E/TC:? 0 fsr 0x00000005 ttbr0 0x0e19206a ttbr1 0x0e18806a cidr 0x2 E/TC:? 0 cpu #1 cpsr 0x60000110 E/TC:? 0 r0 0x00000000 r4 0x00115780 r8 0x00000000 r12 0x00115658 E/TC:? 0 r1 0x00000001 r5 0x0011fb8c r9 0x00000000 sp 0x001156a0 E/TC:? 0 r2 0x00000000 r6 0x60000110 r10 0x00000000 lr 0x00000000 E/TC:? 0 r3 0x00000000 r7 0x00000000 r11 0x001156bc pc 0x00000000 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: arm E/LD: region 0: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x00104000 pa 0x0e302000 size 0x00a000 flags r-xs (ldelf) E/LD: region 2: va 0x0010e000 pa 0x0e30c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x0010f000 pa 0x0e30d000 size 0x003000 flags rw-s (ldelf) E/LD: region 4: va 0x00112000 pa 0x0e310000 size 0x001000 flags r--s E/LD: region 5: va 0x00113000 pa 0x0e444000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x0011b000 pa 0x00001000 size 0x024000 flags r-xs [0] E/LD: region 7: va 0x0013f000 pa 0x00025000 size 0x10f000 flags rw-s [0] E/LD: region 8: va 0x00266000 pa 0x00000000 size 0x003000 flags r-xs [1] E/LD: region 9: va 0x00269000 pa 0x00002000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x00300000 pa 0x40a67570 size 0x001000 flags rw-- (param) E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x0011b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x00266000 E/LD: Call stack: E/LD: 0x00000000 Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 5, 2019
When CFG_FTRACE_SUPPORT=y, thumb mode should not be used in TA code, because the ftrace code assumes arm instructions. Therefore we have to pass the -marm flag to the compiler and assembler. This is correctrly done for the C compiler but not for the assembler -- fix that. The same fix applies for assembler files in the TEE core when CFG_SYSCALL_FTRACE=y. Fixes a crash in the setjmp()/longjmp() test of xtest 1006 when GCC 6.2 is used to build the user space libutils.a (more precisely: lib/libutils/isoc/arch/arm/setjmp_a32.S): E/TC:? 0 User TA prefetch-abort at address 0x0 (translation fault) E/TC:? 0 fsr 0x00000005 ttbr0 0x0e19206a ttbr1 0x0e18806a cidr 0x2 E/TC:? 0 cpu #1 cpsr 0x60000110 E/TC:? 0 r0 0x00000000 r4 0x00115780 r8 0x00000000 r12 0x00115658 E/TC:? 0 r1 0x00000001 r5 0x0011fb8c r9 0x00000000 sp 0x001156a0 E/TC:? 0 r2 0x00000000 r6 0x60000110 r10 0x00000000 lr 0x00000000 E/TC:? 0 r3 0x00000000 r7 0x00000000 r11 0x001156bc pc 0x00000000 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: arm E/LD: region 0: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x00104000 pa 0x0e302000 size 0x00a000 flags r-xs (ldelf) E/LD: region 2: va 0x0010e000 pa 0x0e30c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x0010f000 pa 0x0e30d000 size 0x003000 flags rw-s (ldelf) E/LD: region 4: va 0x00112000 pa 0x0e310000 size 0x001000 flags r--s E/LD: region 5: va 0x00113000 pa 0x0e444000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x0011b000 pa 0x00001000 size 0x024000 flags r-xs [0] E/LD: region 7: va 0x0013f000 pa 0x00025000 size 0x10f000 flags rw-s [0] E/LD: region 8: va 0x00266000 pa 0x00000000 size 0x003000 flags r-xs [1] E/LD: region 9: va 0x00269000 pa 0x00002000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x00300000 pa 0x40a67570 size 0x001000 flags rw-- (param) E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x0011b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x00266000 E/LD: Call stack: E/LD: 0x00000000 Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 6, 2019
When CFG_FTRACE_SUPPORT=y, thumb mode should not be used in TA code, because the ftrace code assumes arm instructions. Therefore we have to pass the -marm switch to the compiler and assembler. This is correctly done for the C compiler but not for the assembler. The same applies to assembler files in the TEE core when CFG_SYSCALL_FTRACE=y. More generally and for simplicity, we will assume that all _a32.S files should be compiled in arm mode and therefore add -marm to arm32-platform-aflags. Any exception can be handled via file-specific flags in sub.mk. Fixes a crash in the setjmp()/longjmp() test of xtest 1006 when Linaro's GCC 6.2 is used to build the user space libutils.a (more precisely: lib/libutils/isoc/arch/arm/setjmp_a32.S): E/TC:? 0 User TA prefetch-abort at address 0x0 (translation fault) E/TC:? 0 fsr 0x00000005 ttbr0 0x0e19206a ttbr1 0x0e18806a cidr 0x2 E/TC:? 0 cpu #1 cpsr 0x60000110 E/TC:? 0 r0 0x00000000 r4 0x00115780 r8 0x00000000 r12 0x00115658 E/TC:? 0 r1 0x00000001 r5 0x0011fb8c r9 0x00000000 sp 0x001156a0 E/TC:? 0 r2 0x00000000 r6 0x60000110 r10 0x00000000 lr 0x00000000 E/TC:? 0 r3 0x00000000 r7 0x00000000 r11 0x001156bc pc 0x00000000 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: arm E/LD: region 0: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x00104000 pa 0x0e302000 size 0x00a000 flags r-xs (ldelf) E/LD: region 2: va 0x0010e000 pa 0x0e30c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x0010f000 pa 0x0e30d000 size 0x003000 flags rw-s (ldelf) E/LD: region 4: va 0x00112000 pa 0x0e310000 size 0x001000 flags r--s E/LD: region 5: va 0x00113000 pa 0x0e444000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x0011b000 pa 0x00001000 size 0x024000 flags r-xs [0] E/LD: region 7: va 0x0013f000 pa 0x00025000 size 0x10f000 flags rw-s [0] E/LD: region 8: va 0x00266000 pa 0x00000000 size 0x003000 flags r-xs [1] E/LD: region 9: va 0x00269000 pa 0x00002000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x00300000 pa 0x40a67570 size 0x001000 flags rw-- (param) E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x0011b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x00266000 E/LD: Call stack: E/LD: 0x00000000 Note: the crash is due to the fact that the compiler was configured for -mthumb by default, whereas Arm's GCC 8.3 for instance defaults to -marm. The compiler switches can be checked with: $ echo 'void f() {};' | \ arm-linux-gnueabihf-gcc -frecord-gcc-switches -xc -c - -o test $ readelf -p .GCC.command.line test Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 6, 2019
When CFG_FTRACE_SUPPORT=y, thumb mode should not be used in TA code, because the ftrace code assumes arm instructions. Therefore we have to pass the -marm switch to the compiler and assembler. This is correctly done for the C compiler but not for the assembler. The same applies to assembler files in the TEE core when CFG_SYSCALL_FTRACE=y. More generally and for simplicity, we will assume that all _a32.S files should be compiled in arm mode and therefore add -marm to arm32-platform-aflags. Any exception can be handled via file-specific flags in sub.mk. Fixes a crash in the setjmp()/longjmp() test of xtest 1006 when Linaro's GCC 6.2 is used to build the user space libutils.a (more precisely: lib/libutils/isoc/arch/arm/setjmp_a32.S): E/TC:? 0 User TA prefetch-abort at address 0x0 (translation fault) E/TC:? 0 fsr 0x00000005 ttbr0 0x0e19206a ttbr1 0x0e18806a cidr 0x2 E/TC:? 0 cpu #1 cpsr 0x60000110 E/TC:? 0 r0 0x00000000 r4 0x00115780 r8 0x00000000 r12 0x00115658 E/TC:? 0 r1 0x00000001 r5 0x0011fb8c r9 0x00000000 sp 0x001156a0 E/TC:? 0 r2 0x00000000 r6 0x60000110 r10 0x00000000 lr 0x00000000 E/TC:? 0 r3 0x00000000 r7 0x00000000 r11 0x001156bc pc 0x00000000 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: arm E/LD: region 0: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x00104000 pa 0x0e302000 size 0x00a000 flags r-xs (ldelf) E/LD: region 2: va 0x0010e000 pa 0x0e30c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x0010f000 pa 0x0e30d000 size 0x003000 flags rw-s (ldelf) E/LD: region 4: va 0x00112000 pa 0x0e310000 size 0x001000 flags r--s E/LD: region 5: va 0x00113000 pa 0x0e444000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x0011b000 pa 0x00001000 size 0x024000 flags r-xs [0] E/LD: region 7: va 0x0013f000 pa 0x00025000 size 0x10f000 flags rw-s [0] E/LD: region 8: va 0x00266000 pa 0x00000000 size 0x003000 flags r-xs [1] E/LD: region 9: va 0x00269000 pa 0x00002000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x00300000 pa 0x40a67570 size 0x001000 flags rw-- (param) E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x0011b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x00266000 E/LD: Call stack: E/LD: 0x00000000 Note: the crash is due to the fact that the compiler was configured for -mthumb by default, whereas Arm's GCC 8.3 for instance defaults to -marm. The compiler switches can be checked with: $ echo 'void f() {};' | \ arm-linux-gnueabihf-gcc -frecord-gcc-switches -xc -c - -o test $ readelf -p .GCC.command.line test Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 6, 2019
When CFG_FTRACE_SUPPORT=y, thumb mode should not be used in TA code, because the ftrace code assumes arm instructions. Therefore we have to pass the -marm switch to the compiler and assembler. This is correctly done for the C compiler but not for the assembler. The same applies to assembler files in the TEE core when CFG_SYSCALL_FTRACE=y. More generally and for simplicity, we will assume that all _a32.S files should be compiled in arm mode and therefore add -marm to arm32-platform-aflags. Any exception can be handled via file-specific flags in sub.mk. Fixes a crash in the setjmp()/longjmp() test of xtest 1006 when Linaro's GCC 6.2 is used to build the user space libutils.a (more precisely: lib/libutils/isoc/arch/arm/setjmp_a32.S): E/TC:? 0 User TA prefetch-abort at address 0x0 (translation fault) E/TC:? 0 fsr 0x00000005 ttbr0 0x0e19206a ttbr1 0x0e18806a cidr 0x2 E/TC:? 0 cpu #1 cpsr 0x60000110 E/TC:? 0 r0 0x00000000 r4 0x00115780 r8 0x00000000 r12 0x00115658 E/TC:? 0 r1 0x00000001 r5 0x0011fb8c r9 0x00000000 sp 0x001156a0 E/TC:? 0 r2 0x00000000 r6 0x60000110 r10 0x00000000 lr 0x00000000 E/TC:? 0 r3 0x00000000 r7 0x00000000 r11 0x001156bc pc 0x00000000 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: arm E/LD: region 0: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x00104000 pa 0x0e302000 size 0x00a000 flags r-xs (ldelf) E/LD: region 2: va 0x0010e000 pa 0x0e30c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x0010f000 pa 0x0e30d000 size 0x003000 flags rw-s (ldelf) E/LD: region 4: va 0x00112000 pa 0x0e310000 size 0x001000 flags r--s E/LD: region 5: va 0x00113000 pa 0x0e444000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x0011b000 pa 0x00001000 size 0x024000 flags r-xs [0] E/LD: region 7: va 0x0013f000 pa 0x00025000 size 0x10f000 flags rw-s [0] E/LD: region 8: va 0x00266000 pa 0x00000000 size 0x003000 flags r-xs [1] E/LD: region 9: va 0x00269000 pa 0x00002000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x00300000 pa 0x40a67570 size 0x001000 flags rw-- (param) E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x0011b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x00266000 E/LD: Call stack: E/LD: 0x00000000 Note: the crash is due to the fact that the compiler was configured for -mthumb by default, whereas Arm's GCC 8.3 for instance defaults to -marm. The compiler switches can be checked with: $ echo 'void f() {};' | \ arm-linux-gnueabihf-gcc -frecord-gcc-switches -xc -c - -o test $ readelf -p .GCC.command.line test Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Sumit Garg <[email protected]>
jforissier
added a commit
that referenced
this pull request
Nov 8, 2019
When CFG_FTRACE_SUPPORT=y, thumb mode should not be used in TA code, because the ftrace code assumes arm instructions. Therefore we have to pass the -marm switch to the compiler and assembler. This is correctly done for the C compiler but not for the assembler. The same applies to assembler files in the TEE core when CFG_SYSCALL_FTRACE=y. More generally and for simplicity, we will assume that all _a32.S files should be compiled in arm mode and therefore add -marm to arm32-platform-aflags. Any exception can be handled via file-specific flags in sub.mk. Fixes a crash in the setjmp()/longjmp() test of xtest 1006 when Linaro's GCC 6.2 is used to build the user space libutils.a (more precisely: lib/libutils/isoc/arch/arm/setjmp_a32.S): E/TC:? 0 User TA prefetch-abort at address 0x0 (translation fault) E/TC:? 0 fsr 0x00000005 ttbr0 0x0e19206a ttbr1 0x0e18806a cidr 0x2 E/TC:? 0 cpu #1 cpsr 0x60000110 E/TC:? 0 r0 0x00000000 r4 0x00115780 r8 0x00000000 r12 0x00115658 E/TC:? 0 r1 0x00000001 r5 0x0011fb8c r9 0x00000000 sp 0x001156a0 E/TC:? 0 r2 0x00000000 r6 0x60000110 r10 0x00000000 lr 0x00000000 E/TC:? 0 r3 0x00000000 r7 0x00000000 r11 0x001156bc pc 0x00000000 E/LD: Status of TA 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b E/LD: arch: arm E/LD: region 0: va 0x00102000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf) E/LD: region 1: va 0x00104000 pa 0x0e302000 size 0x00a000 flags r-xs (ldelf) E/LD: region 2: va 0x0010e000 pa 0x0e30c000 size 0x001000 flags rw-s (ldelf) E/LD: region 3: va 0x0010f000 pa 0x0e30d000 size 0x003000 flags rw-s (ldelf) E/LD: region 4: va 0x00112000 pa 0x0e310000 size 0x001000 flags r--s E/LD: region 5: va 0x00113000 pa 0x0e444000 size 0x003000 flags rw-s (stack) E/LD: region 6: va 0x0011b000 pa 0x00001000 size 0x024000 flags r-xs [0] E/LD: region 7: va 0x0013f000 pa 0x00025000 size 0x10f000 flags rw-s [0] E/LD: region 8: va 0x00266000 pa 0x00000000 size 0x003000 flags r-xs [1] E/LD: region 9: va 0x00269000 pa 0x00002000 size 0x002000 flags rw-s [1] E/LD: region 10: va 0x00300000 pa 0x40a67570 size 0x001000 flags rw-- (param) E/LD: [0] 5b9e0e40-2636-11e1-ad9e-0002a5d5c51b @ 0x0011b000 E/LD: [1] ffd2bded-ab7d-4988-95ee-e4962fff7154 @ 0x00266000 E/LD: Call stack: E/LD: 0x00000000 Note: the crash is due to the fact that the compiler was configured for -mthumb by default, whereas Arm's GCC 8.3 for instance defaults to -marm. The compiler switches can be checked with: $ echo 'void f() {};' | \ arm-linux-gnueabihf-gcc -frecord-gcc-switches -xc -c - -o test $ readelf -p .GCC.command.line test Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]> Reviewed-by: Sumit Garg <[email protected]>
jforissier
added a commit
that referenced
this pull request
Aug 26, 2020
Tracing the log syscall is of very little value since it will generate some output to the console anyways. Worse, it pollutes the TA output in case of a panic or an abort. For example: o regression_4005.1 AE case 0 algo 0x40000710 line 2819 F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#15 (syscall_cryp_state_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#30 (syscall_cryp_obj_populate) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#29 (syscall_cryp_obj_reset) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#31 (syscall_cryp_obj_copy) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#28 (syscall_cryp_obj_close) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#34 (syscall_authenc_init) F/TC:?? 0 trace_syscall:132 syscall #2 (syscall_panic) E/TC:?? 0 E/TC:?? 0 TA panicked with code 0xffff0006 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: Status of TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: arch: aarch64 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 0: va 0x40004000 pa 0x100062d000 size 0x002000 flags rw-s (ldelf) F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 1: va 0x40006000 pa 0x100062f000 size 0x00d000 flags r-xs (ldelf) ... Therefore, skip the trace if the syscall number it TEE_SCN_LOG. Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Aug 26, 2020
Tracing the log syscall is of very little value since it will generate some output to the console anyways. Worse, it pollutes the TA output in case of a panic or an abort. For example: o regression_4005.1 AE case 0 algo 0x40000710 line 2819 F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#15 (syscall_cryp_state_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#30 (syscall_cryp_obj_populate) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#29 (syscall_cryp_obj_reset) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#31 (syscall_cryp_obj_copy) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#28 (syscall_cryp_obj_close) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#34 (syscall_authenc_init) F/TC:?? 0 trace_syscall:132 syscall #2 (syscall_panic) E/TC:?? 0 E/TC:?? 0 TA panicked with code 0xffff0006 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: Status of TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: arch: aarch64 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 0: va 0x40004000 pa 0x100062d000 size 0x002000 flags rw-s (ldelf) F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 1: va 0x40006000 pa 0x100062f000 size 0x00d000 flags r-xs (ldelf) ... Therefore, skip the trace if the syscall number it TEE_SCN_LOG. Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
jforissier
added a commit
that referenced
this pull request
Aug 27, 2020
Tracing the log syscall is of very little value since it will generate some output to the console anyways. Worse, it pollutes the TA output in case of a panic or an abort. For example: o regression_4005.1 AE case 0 algo 0x40000710 line 2819 F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#15 (syscall_cryp_state_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#27 (syscall_cryp_obj_alloc) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#30 (syscall_cryp_obj_populate) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#29 (syscall_cryp_obj_reset) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#31 (syscall_cryp_obj_copy) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#24 (syscall_cryp_obj_get_info) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#28 (syscall_cryp_obj_close) F/TC:?? 0 trace_syscall:132 syscall OP-TEE#34 (syscall_authenc_init) F/TC:?? 0 trace_syscall:132 syscall #2 (syscall_panic) E/TC:?? 0 E/TC:?? 0 TA panicked with code 0xffff0006 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: Status of TA cb3e5ba0-adf1-11e0-998b-0002a5d5c51b F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: arch: aarch64 F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 0: va 0x40004000 pa 0x100062d000 size 0x002000 flags rw-s (ldelf) F/TC:?? 0 trace_syscall:132 syscall #1 (syscall_log) E/LD: region 1: va 0x40006000 pa 0x100062f000 size 0x00d000 flags r-xs (ldelf) ... Therefore, skip the trace if the syscall number it TEE_SCN_LOG. Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Mar 8, 2021
Adds an assert() that mbedtls_mpi_write_binary() succeeds in crypto_bignum_bn2bin(). This fixes coverity scan: CID 1501843 (#1 of 1): Unchecked return value (CHECKED_RETURN). Reviewed-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Mar 8, 2021
Adds an assert() that mbedtls_mpi_copy() succeeds in crypto_bignum_copy(). This fixes coverity scan: CID 1501791 (#1 of 1): Unchecked return value (CHECKED_RETURN) Reviewed-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Mar 8, 2021
The gcd parameter passed to TEE_BigIntComputeExtendedGcd() must not be NULL so skip the unnecessary NULL check. This fixes coverity scan: CID 1501842 (#1 of 1): Dereference after null check (FORWARD_NULL) Reviewed-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Mar 8, 2021
Adds an assert() that snprintf() succeeds in file_num_to_str(). This fixes coverity scan: CID 1501823 (#1 of 1): Unchecked return value (CHECKED_RETURN) Reviewed-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Mar 8, 2021
system_dlsym() takes a uuid in one of the memref parameters. Prior to this patch that memref wasn't checked correctly in all cases. system_dlsym() passes the uuid to ldelf_dlsym() which uses this uuid so the pointer must be valid and of the expected size. Fix this by checking that the pointer is non-NULL and of the correct size. This fixes coverity scan: CID 1501812 (#1 of 1): Dereference after null check (FORWARD_NULL) Fixes: ebef121 ("core, ldelf: add support for runtime loading of shared libraries") Reviewed-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Mar 8, 2021
Adds another check of srcLen in TEE_CipherDoFinal() before calling tee_buffer_update() to make sure that we don't dereference destLen when it's NULL. This fixes coverity scan: CID 1501811 (#1 of 1): Dereference after null check (FORWARD_NULL) Reviewed-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Mar 8, 2021
Adds a check for the return value from snprintf() in add_res_mem_dt_node(). In case snprintf() has failed of truncates the output a debug warning in the log. This fixes coverity scan: CID 1501804 (#1 of 1): Unchecked return value (CHECKED_RETURN) Reviewed-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Jun 24, 2021
Adds checks in e32_relocate() that sym_tab is assigned a symbol table before using it. This fixes coverity scan: CID 1501826 (#1 of 3): Explicit null dereferenced (FORWARD_NULL) CID 1501826 (#2 of 3): Explicit null dereferenced (FORWARD_NULL) CID 1501826 (#3 of 3): Explicit null dereferenced (FORWARD_NULL) Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Jun 24, 2021
In tee_fs_dirfile_get_tmp() dirh->files is checked to be not NULL leading but at another place dirh->nbits is checked instead before accessing dirh->files. Both checks are OK since dirh->files mustn't be NULL if dirh->nbits is larger than 0. This confuses coverity to emit a warning, so change the function to check dirh->nbits instead. This fixes coverity scan: CID 1501821 (#1 of 1): Dereference after null check (FORWARD_NULL) Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Jun 24, 2021
In populate_files() db->files is checked to be not NULL leading but at another place db->nbits is checked instead before accessing db->files. Both checks are OK since db->files mustn't be NULL if db->nbits is larger than 0. This confuses coverity to emit a warning, so change the function to check db->nbits instead. This fixes coverity scan: CID 1501793 (#1 of 1): Dereference after null check (FORWARD_NULL) Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Aug 10, 2021
Specified in: PKCS OP-TEE#11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Plus Errata 01 2.1.4 PKCS #1 RSA key pair generation Signed-off-by: Vesa Jääskeläinen <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Aug 10, 2021
Add support for performing RSA signing & verification operations for: - PKCS #1 v1.5 RSA with supplied hash value - Multi stage MD5 - Multi stage SHA-1 - Multi stage SHA-224 - Multi stage SHA-256 - Multi stage SHA-384 - Multi stage SHA-512 Specified in: PKCS OP-TEE#11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Plus Errata 01 2.1 RSA Signed-off-by: Vesa Jääskeläinen <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Aug 10, 2021
Add support for performing RSA PSS signing & verification operations for: - PKCS #1 RSA PSS with supplied hash value - Multi stage SHA-1 - Multi stage SHA-224 - Multi stage SHA-256 - Multi stage SHA-384 - Multi stage SHA-512 Specified in: PKCS OP-TEE#11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Plus Errata 01 2.1.10 PKCS #1 RSA PSS Signed-off-by: Vesa Jääskeläinen <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Aug 10, 2021
Add support for performing PKCS #1 RSA OAEP encryption & decryption operations for: - MGF1 SHA-1 - MGF1 SHA-224 - MGF1 SHA-256 - MGF1 SHA-384 - MGF1 SHA-512 Specified in: PKCS OP-TEE#11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Plus Errata 01 2.1.8 PKCS #1 RSA OAEP Signed-off-by: Vesa Jääskeläinen <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Aug 10, 2021
Different requirements are in place when importing RSA public key vs. generaing a new RSA key pair. Specified in: PKCS OP-TEE#11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 Plus Errata 01 2.1.2 RSA public key objects and 2.1.4 PKCS #1 RSA key pair generation Signed-off-by: Vesa Jääskeläinen <[email protected]> Reviewed-by: Etienne Carriere <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Jan 28, 2022
Updates ree_fs_open() to close the dirfile on error. This should take care of the rare case were the internal file handle in the dirfile has been closed due to an error. Fixes an error like: E/TC:1 1 Core data-abort at address 0xc0 (translation fault) E/TC:1 1 esr 0x96000006 ttbr0 0x600000e19a020 ttbr1 0x00000000 cidr 0x0 E/TC:1 1 cpu #1 cpsr 0x00000004 E/TC:1 1 x0 00000000000000c0 x1 0000000000000078 E/TC:1 1 x2 000000000e1a0c88 x3 000000000e1a0c28 E/TC:1 1 x4 0000000000000078 x5 000000000e128220 E/TC:1 1 x6 000000000000001f x7 0000000000000000 E/TC:1 1 x8 0000000000000000 x9 0000000000000000 E/TC:1 1 x10 0000000000000000 x11 0000000000000000 E/TC:1 1 x12 0000000000000000 x13 0000000040014f80 E/TC:1 1 x14 0000000000000000 x15 0000000000000000 E/TC:1 1 x16 000000000e12f318 x17 0000000000000000 E/TC:1 1 x18 0000000000000000 x19 0000000000000078 E/TC:1 1 x20 0000000000000000 x21 000000000e1a0c28 E/TC:1 1 x22 00000000ffffffff x23 000000000e1a0c88 E/TC:1 1 x24 000000000e1891c4 x25 000000000e17d1b0 E/TC:1 1 x26 000000000e17de50 x27 000000000e1891c4 E/TC:1 1 x28 0000000000000000 x29 000000000e1a0b90 E/TC:1 1 x30 000000000e128254 elr 000000000e128260 E/TC:1 1 sp_el0 000000000e1a0b90 E/TC:1 1 TEE load address @ 0xe100000 E/TC:1 1 Call stack: E/TC:1 1 0x0e128260 ree_fs_read_primitive at core/tee/tee_ree_fs.c:311 E/TC:1 1 0x0e129324 read_dent at core/tee/fs_dirfile.c:89 E/TC:1 1 0x0e129770 tee_fs_dirfile_find at core/tee/fs_dirfile.c:213 E/TC:1 1 0x0e128f1c set_name at core/tee/tee_ree_fs.c:664 E/TC:1 1 0x0e125954 tee_svc_storage_init_file at core/tee/tee_svc_storage.c:297 E/TC:1 1 0x0e10d514 tee_svc_do_call at core/arch/arm/tee/arch_svc_a64.S:140 E/TC:1 1 0x0e1062ec thread_svc_handler at core/arch/arm/kernel/thread.c:1585 (discriminator 4) E/TC:1 1 0x0e103618 el0_svc at core/arch/arm/kernel/thread_a64.S:651 Acked-by: Jerome Forissier <[email protected]> Signed-off-by: Jens Wiklander <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Feb 28, 2022
Add size check in the crypto driver for RSA sign and verify functions. For both functions, the encoded message length has some size constraints [1]. [1]: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography https://datatracker.ietf.org/doc/html/rfc3447#section-9.1.1 Fixes: f5a70e3 ("drivers: crypto: generic resources for crypto device driver - RSA") Signed-off-by: Cedric Neveux <[email protected]> Acked-by: Etienne Carriere <[email protected]>
jforissier
pushed a commit
that referenced
this pull request
Mar 26, 2024
XEN fails to boot linux when cpu is selected as max with following kernel crash. Hence revert to using cortex-a57 when XEN_BOOT is selected. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] kernel BUG at arch/arm64/kernel/traps.c:498! [ 0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-gdbeb6ea978fc #1 [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : do_undefinstr+0x2bc/0x2e0 [ 0.000000] lr : do_undefinstr+0x2c8/0x2e0 [ 0.000000] sp : ffffd399cddc3c60 [ 0.000000] x29: ffffd399cddc3c60 x28: ffffd399cddd34c0 x27: 0000000000000000 [ 0.000000] x26: 0000000000000000 x25: 0000000000000000 x24: ffffd399cd830008 [ 0.000000] x23: 00000000000000c5 x22: ffffd399cd7810bc x21: ffffd399cddc3e30 [ 0.000000] x20: 00000000d5182101 x19: ffffd399cddc3ce0 x18: 0000000000000014 [ 0.000000] x17: 0000000049426f60 x16: 0000000056a84232 x15: 0000000099ac15ae [ 0.000000] x14: 00000000ab810c49 x13: 501bac190a4c3eb1 x12: 89c8a6a0aab2e7c5 [ 0.000000] x11: 00000000c16d9c19 x10: 00000000e4fb46a5 x9 : 00000000d78a73db [ 0.000000] x8 : 0000000000000014 x7 : 501bac190a4c3eb1 x6 : 89c8a6a0aab2e7c5 [ 0.000000] x5 : ffffd399cddd5910 x4 : 0000000000000000 x3 : ffffd399ce0e70f8 [ 0.000000] x2 : 0000000000000000 x1 : ffffd399cddd34c0 x0 : 00000000000000c5 [ 0.000000] Call trace: [ 0.000000] do_undefinstr+0x2bc/0x2e0 [ 0.000000] el1_undef+0x2c/0x4c [ 0.000000] el1h_64_sync_handler+0x84/0xd0 [ 0.000000] el1h_64_sync+0x78/0x7c [ 0.000000] start_kernel+0x4c4/0x664 [ 0.000000] __primary_switched+0xc0/0xc8 [ 0.000000] Code: 17ffff8d a9425bf5 17ffffb1 a9025bf5 (d4210000) [ 0.000000] ---[ end trace 32823fcd1957a64b ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- Signed-off-by: Ruchika Gupta <[email protected]> Reviewed-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Aug 14, 2024
…uild Fix an issue with the build number in the version string. While at it, factor out the duplicated code into mk/macros.mk. Before: $ rm -rf out/ $ make out/arm-plat-vexpress/core/version.o UPD out/arm-plat-vexpress/core/.buildcount GEN out/arm-plat-vexpress/core/version.o cat: out/arm-plat-vexpress/core/.buildcount: No such file or directory In addition to the error message, note the missing build number after the hash sign: $ strings out/arm-plat-vexpress/core/version.o | grep UTC 4.3.0-48-g9c97e7d52 (gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)) # Wed Aug 14 16:17:07 UTC 2024 arm After: $ rm -rf out/ $ make out/arm-plat-vexpress/core/version.o UPD out/arm-plat-vexpress/core/.buildcount GEN out/arm-plat-vexpress/core/version.o $ strings out/arm-plat-vexpress/core/version.o | grep UTC 4.3.0-48-g9c97e7d52-dev (gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)) #1 Wed Aug 14 16:17:24 UTC 2024 arm Signed-off-by: Jerome Forissier <[email protected]>
jforissier
added a commit
that referenced
this pull request
Aug 16, 2024
…uild Fix an issue with the build number in the version string. While at it, factor out the duplicated code into mk/macros.mk. Before: $ rm -rf out/ $ make out/arm-plat-vexpress/core/version.o UPD out/arm-plat-vexpress/core/.buildcount GEN out/arm-plat-vexpress/core/version.o cat: out/arm-plat-vexpress/core/.buildcount: No such file or directory In addition to the error message, note the missing build number after the hash sign: $ strings out/arm-plat-vexpress/core/version.o | grep UTC 4.3.0-48-g9c97e7d52 (gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)) # Wed Aug 14 16:17:07 UTC 2024 arm After: $ rm -rf out/ $ make out/arm-plat-vexpress/core/version.o UPD out/arm-plat-vexpress/core/.buildcount GEN out/arm-plat-vexpress/core/version.o $ strings out/arm-plat-vexpress/core/version.o | grep UTC 4.3.0-48-g9c97e7d52-dev (gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)) #1 Wed Aug 14 16:17:24 UTC 2024 arm Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
jforissier
added a commit
that referenced
this pull request
Sep 20, 2024
…uild Fix an issue with the build number in the version string. While at it, factor out the duplicated code into mk/macros.mk. Before: $ rm -rf out/ $ make out/arm-plat-vexpress/core/version.o UPD out/arm-plat-vexpress/core/.buildcount GEN out/arm-plat-vexpress/core/version.o cat: out/arm-plat-vexpress/core/.buildcount: No such file or directory In addition to the error message, note the missing build number after the hash sign: $ strings out/arm-plat-vexpress/core/version.o | grep UTC 4.3.0-48-g9c97e7d52 (gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)) # Wed Aug 14 16:17:07 UTC 2024 arm After: $ rm -rf out/ $ make out/arm-plat-vexpress/core/version.o UPD out/arm-plat-vexpress/core/.buildcount GEN out/arm-plat-vexpress/core/version.o $ strings out/arm-plat-vexpress/core/version.o | grep UTC 4.3.0-48-g9c97e7d52-dev (gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)) #1 Wed Aug 14 16:17:24 UTC 2024 arm Signed-off-by: Jerome Forissier <[email protected]> Reviewed-by: Jens Wiklander <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: Jerome Forissier [email protected]