Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gcov: Enhance gcov #126

Merged
merged 11 commits into from
Jan 13, 2025
Merged

Gcov: Enhance gcov #126

merged 11 commits into from
Jan 13, 2025

Conversation

W-M-R
Copy link
Contributor

@W-M-R W-M-R commented Jan 8, 2025

Note: Please adhere to Contributing Guidelines.

Summary

    Currently, there are four code coverage statistics implementations:
    1. GCC native implementation
    2. CLANG native implementation
    3. GCC coverage nuttx mini version
    4. CLANG coverage nuttx mini version
    Coverage Support:
                                                   GCC native implementation  CLANG native implementation  GCC coverage nuttx mini version  CLANG coverage nuttx mini version
    Compiler version requirements                              ALL                       ALL                         GCC 13.2 and below             CLANG 17.0 and below
    Program coverage statistics support   Main program          √                         √                                  √                               √
    Program coverage statistics support   Interrupt program     X                         √                                  √                               √
    Configuration options                         CONFIG_COVERAGE_TOOLCHAIN    CONFIG_COVERAGE_COMPILER_RT          CONFIG_COVERAGE_MINI            CONFIG_COVERAGE_MINI
    Platform Support            ARM                             √                         √                                  √                               √
                                ARM64                           √                                                            √
                                                                                                             

Impact

Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.

Testing

Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.

@CLAassistant
Copy link

CLAassistant commented Jan 8, 2025

CLA assistant check
All committers have signed the CLA.

Gary-Hobson and others added 11 commits January 13, 2025 11:21
In devices without storage media, you can export data to the
command line and then generate the corresponding gcda file

It can save the result output by calling __gcov_info_to_gcda
The usage is similar to:
https://gcc.gnu.org/onlinedocs/gcc/Freestanding-Environments.html#Profiling-and-Test-Coverage-in-Freestanding-Environments

Usage:
 ./tools/configure.sh qemu-armv7a:nsh
Modify the configuration
+CONFIG_COVERAGE_ALL=y
+CONFIG_COVERAGE_MINI=y
+CONFIG_SYSTEM_GCOV=y
Run:
qemu-system-arm -cpu cortex-a7 -nographic -smp 4 \
     -machine virt,virtualization=off,gic-version=2 \
     -net none -chardev stdio,id=con,mux=on -serial chardev:con \
     -mon chardev=con,mode=readline -kernel ./nuttx/nuttx -semihosting -s | tee gcov.txt
./nuttx/tools/gcov_convert.py -i ./gcov.txt
./nuttx/tools/gcov.sh -t arm-none-eabi-gcov

Signed-off-by: yinshengkai <[email protected]>
CC:  gcov.c gcov.c: In function 'gcov_stdout_dump':
gcov.c:146:50: error: passing argument 3 of '__gcov_info_to_gcda' from incompatible pointer type [-Werror=incompatible-pointer-types]
  146 |       __gcov_info_to_gcda(info, stdout_filename, stdout_dump, NULL, &arg);
      |                                                  ^~~~~~~~~~~
      |                                                  |
      |                                                  void (*)(const void *, size_t,  void *) {aka void (*)(const void *, long unsigned int,  void *)}
In file included from gcov.c:25:
/mnt/vela/github/NX/nuttx/include/gcov.h:139:44: note: expected 'void (*)(const void *, unsigned int,  void *)' but argument is of type 'void (*)(const void *, size_t,  void *)' {aka 'void (*)(const void *, long unsigned int,  void *)'}
  139 |                                 FAR void (*dump)(FAR const void *,
      |                                     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
  140 |                                                  unsigned int, FAR void *),
      |                                                  ~~~~~~~~~~~~~~~~~~~~~~~~~

libgcc/gcov.c: In function 'gcov_process_path.constprop':
libgcc/gcov.c:235:29: error: 'filename' may be used uninitialized [-Werror=maybe-uninitialized]
  235 |       tokens[token_count++] = filename;
      |       ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
libgcc/gcov.c:189:13: note: 'filename' was declared here
  189 |   FAR char *filename;

Signed-off-by: wangmingrong1 <[email protected]>
Some functions will insert these functions:
void __gcov_execve(void)
{
}
void __gcov_execv(void)
{
}
void __gcov_fork(void)
{
}

Signed-off-by: wangmingrong1 <[email protected]>
(.text.ltp_interfaces_sem_unlink_2_2_main+0xd8): undefined reference to `__gcov_execlk'

Signed-off-by: wangmingrong1 <[email protected]>
After code coverage is enabled, fork will be replaced by __gcov_fork

Signed-off-by: wangmingrong1 <[email protected]>
When enable CONFIG_STACK_CANARIES, in general, the stack check in the __gcov_fork function is:
" return fork();
18: e59f3020 ldr r3, [pc, open-vela#32] @ 40 <__gcov_fork+0x40>
1c: e5932000 ldr r2, [r3]
20: e59d3004 ldr r3, [sp, open-vela#4]
24: e0332002 eors r2, r3, r2
28: e3a03000 mov r3, #0
2c: 1a000002 bne 3c <__gcov_fork+0x3c>"
r3 is obtained by taking the value of sp offset. But after opening thumb, the second comparison value in
"8c6: 4a06 ldr r2, [pc, open-vela#24] @ (8e0 <__gcov_fork+0x30>)
8c8: 6811 ldr r1, [r2, #0]
8ca: 687a ldr r2, [r7, open-vela#4]
8cc: 4051 eors r1, r2"
is obtained through r7. Since r7 stores the stack address at this time, which stores the address of the parent process, the stack out of bounds will occur in the child process

Signed-off-by: wangmingrong1 <[email protected]>
Signed-off-by: wangmingrong1 <[email protected]>
@xiaoxiang781216 xiaoxiang781216 merged commit be21e32 into open-vela:dev Jan 13, 2025
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants