-
Notifications
You must be signed in to change notification settings - Fork 41
[DO NOT MERGE] Introduce coredump server #1370
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Summary of Changes
Hello @etiaro, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces a coredump server by integrating it into the boot process of a wide array of embedded projects and targets. The primary goal is to enable robust debugging capabilities by ensuring that coredumps can be generated and collected when system failures occur across different hardware platforms. This change also includes updates to several key submodules, which are likely prerequisites for the coredump server's functionality.
Highlights
- Widespread Coredump Server Integration: The
coredump_serverapplication has been integrated into the boot configuration files (user.plo.yaml) for numerous projects and targets. This ensures that the coredump server is launched as part of the system's startup sequence across various embedded platforms. - Submodule Updates: Several core submodules, including
libphoenix,phoenix-rtos-kernel,phoenix-rtos-tests, andphoenix-rtos-utils, have been updated to their latest commits. These updates likely provide the necessary underlying support and functionality for the newly introduced coredump server.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces the coredump_server application across a wide range of projects and targets, which is a valuable feature for debugging. The changes also include updates to several submodules, likely to support this new functionality.
The implementation is mostly consistent, but I've found a few configuration files where the coredump_server is started after the psh application. To ensure that crashes in psh can be captured, the coredump server should be initialized before it. I've left specific comments with suggestions to correct the startup order in the affected files.
cfafd73 to
807aff5
Compare
Unit Test Results9 612 tests +167 9 011 ✅ +155 51m 51s ⏱️ + 3m 52s Results for commit 4963991. ± Comparison against base commit d388507. This pull request removes 3 and adds 170 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
d7c9582 to
0d285e4
Compare
321c18c to
dba8b34
Compare
8efdeba to
be5701c
Compare
be5701c to
8f140c8
Compare
Adds coredump_server to user.plo.yaml of all targets which don't include it in multi devs Disable Coredump functionality from multi devs by default JIRA: RTOS-1054
8f140c8 to
4963991
Compare
Description
phoenix-rtos/phoenix-rtos-kernel#682
phoenix-rtos/phoenix-rtos-utils#242
phoenix-rtos/phoenix-rtos-corelibs#57
phoenix-rtos/phoenix-rtos-devices#575
Motivation and Context
Types of changes
How Has This Been Tested?
Checklist:
Special treatment