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

Make location meaningful in print_error_report #7609

Merged
merged 1 commit into from Jul 27, 2018

Conversation

Projects
None yet
5 participants
@bremoran
Contributor

bremoran commented Jul 26, 2018

handle_error calls MBED_CALLER_ADDR(), but this is always a location from within platform/mbed_error.c. This is because handle_error is declared static. This does not cause the function to be inlined however. Instead, it is called by each function within mbed_error.c. For example, mbed_error yields this code:

000625c8 <mbed_error>:
   625c8:       b510            push    {r4, lr}
   625ca:       460c            mov     r4, r1
   625cc:       4611            mov     r1, r2
   625ce:       461a            mov     r2, r3
   625d0:       9b02            ldr     r3, [sp, #8]
   625d2:       f7ff feff       bl      623d4 <handle_error>
   625d6:       b968            cbnz    r0, 625f4 <mbed_error+0x2c>
   625d8:       4620            mov     r0, r4
   625da:       f7ff ff67       bl      624ac <print_error_report.constprop.0>
   625de:       f7ff fea8       bl      62332 <core_util_is_isr_active>
   625e2:       b910            cbnz    r0, 625ea <mbed_error+0x22>
   625e4:       f7ff fe9f       bl      62326 <core_util_are_interrupts_enabled>
   625e8:       b908            cbnz    r0, 625ee <mbed_error+0x26>
   625ea:       bf30            wfi
   625ec:       e7fd            b.n     625ea <mbed_error+0x22>
   625ee:       2001            movs    r0, #1
   625f0:       f000 f948       bl      62884 <__wrap_exit>
   625f4:       4800            ldr     r0, [pc, #0]    ; (625f8 <mbed_error+0x30>)
   625f6:       bd10            pop     {r4, pc}
   625f8:       80ff010f        .word   0x80ff010f

Note that at 625d2 there is a bl to handle error. That replaces the LR, which means that ALL calls to mbed_error will report a location of 0x625d6 or 0x625d7 (user vs. supervisor). I do not expect that this was the intention of the code. The simplest fix is to change line 99:

static inline mbed_error_status_t handle_error(mbed_error_status_t error_status, unsigned int error_value, const char *filename, int line_number)

Since handle_error() will be inlined, the link register will be kept the same, so MBED_CALLER_ADDR() will yield the expected result. However, there is no guarantee that the compiler will respect the inline keyword in all circumstances.

The result is that each function that wishes to report its caller must extract its caller. This code cannot be centralised.

I have modified mbed_error.c to report the caller of each error reporting function, rather than the error reporting function itself.

Description

Pull request type

[x] Fix
[ ] Refactor
[ ] New target
[ ] Feature
[ ] Breaking change
Make location meaningful in print_error_report
`handle_error` calls `MBED_CALLER_ADDR()`, but this is always a location from within platform/mbed_error.c. This is because `handle_error` is declared static. This does not cause the function to be inlined however. Instead, it is called by each function within mbed_error.c. For example, mbed_error yields this code:

```
000625c8 <mbed_error>:
   625c8:       b510            push    {r4, lr}
   625ca:       460c            mov     r4, r1
   625cc:       4611            mov     r1, r2
   625ce:       461a            mov     r2, r3
   625d0:       9b02            ldr     r3, [sp, #8]
   625d2:       f7ff feff       bl      623d4 <handle_error>
   625d6:       b968            cbnz    r0, 625f4 <mbed_error+0x2c>
   625d8:       4620            mov     r0, r4
   625da:       f7ff ff67       bl      624ac <print_error_report.constprop.0>
   625de:       f7ff fea8       bl      62332 <core_util_is_isr_active>
   625e2:       b910            cbnz    r0, 625ea <mbed_error+0x22>
   625e4:       f7ff fe9f       bl      62326 <core_util_are_interrupts_enabled>
   625e8:       b908            cbnz    r0, 625ee <mbed_error+0x26>
   625ea:       bf30            wfi
   625ec:       e7fd            b.n     625ea <mbed_error+0x22>
   625ee:       2001            movs    r0, #1
   625f0:       f000 f948       bl      62884 <__wrap_exit>
   625f4:       4800            ldr     r0, [pc, #0]    ; (625f8 <mbed_error+0x30>)
   625f6:       bd10            pop     {r4, pc}
   625f8:       80ff010f        .word   0x80ff010f
```

Note that at `625d2` there is a bl to handle error. That replaces the LR, which means that ALL calls to mbed_error will report a location of 0x625d6 or 0x625d7 (user vs. supervisor). I do not expect that this was the intention of the code. The simplest fix is to change line 99:

```C
static inline mbed_error_status_t handle_error(mbed_error_status_t error_status, unsigned int error_value, const char *filename, int line_number)
```

Since `handle_error()` will be inlined, the link register will be kept the same, so `MBED_CALLER_ADDR()` will yield the expected result. However, there is no guarantee that the compiler will respect the `inline` keyword in all circumstances.

The result is that each function that wishes to report its caller must extract its caller. This code cannot be centralised.

I have modified `mbed_error.c` to report the caller of each error reporting function, rather than the error reporting function itself.
@bremoran

This comment has been minimized.

Contributor

bremoran commented Jul 26, 2018

@0xc0170 0xc0170 requested review from bulislaw and SenRamakri Jul 26, 2018

@cmonr

This comment has been minimized.

Contributor

cmonr commented Jul 26, 2018

@bremoran Updating the description to indicate this is a fix.

@SenRamakri

This comment has been minimized.

Contributor

SenRamakri commented Jul 26, 2018

@bremoran - This is good change, Thanks. The original intention was to capture the address of the mbed_error() caller but I think this probably happened as part of some refactoring afterwards.

@cmonr

This comment has been minimized.

Contributor

cmonr commented Jul 26, 2018

/morph build

@mbed-ci

This comment has been minimized.

mbed-ci commented Jul 27, 2018

Build : SUCCESS

Build number : 2678
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7609/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

@mbed-ci

This comment has been minimized.

@mbed-ci

This comment has been minimized.

@cmonr cmonr merged commit 8292aff into ARMmbed:master Jul 27, 2018

14 checks passed

AWS-CI uVisor Build & Test Success
Details
ci-morph-build build completed
Details
ci-morph-exporter build completed
Details
ci-morph-mbed2-build build completed
Details
ci-morph-test test completed
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
travis-ci/astyle Passed, 793 files
Details
travis-ci/docs Local docs testing has passed
Details
travis-ci/events Passed, runtime is 9642 cycles
Details
travis-ci/gitattributestest Local gitattributestest testing has passed
Details
travis-ci/licence_check Local licence_check testing has passed
Details
travis-ci/littlefs Passed, code size is 9960B
Details
travis-ci/tools-py2.7 Local tools-py2.7 testing has passed
Details

@0xc0170 0xc0170 removed the needs: CI label Jul 27, 2018

pan- pushed a commit to pan-/mbed that referenced this pull request Aug 22, 2018

Merge pull request ARMmbed#7609 from bremoran/patch-2
Make location meaningful in print_error_report
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment