|
Description
|
While performing an analysis of the binary deliverabes changed as a result of some source changes, we happened across a number of odd differences looking like:
platform/SUNW,Sun-Fire-15000/kernel/drv/sparcv9/schpc
NOTE: ELF .rodata1 section difference detected.
NOTE: Difference: 1333,1338c1333,1338
< 0024640 M U T E X _ H E L D ( & s c h p
< 4d555445 585f4845 4c442826 73636870
< 0024660 c _ p - > s c h p c _ m u t e x
< 635f702d 3e736368 70635f6d 75746578
< 0024700 ) \0 \0 \0 \0 \0 \0 \0 . . / . . / . .
< 29000000 00000000 2e2e2f2e 2e2f2e2e
---
> 0024640 ( m u t e x _ o w n e d ( & s c
> 286d7574 65785f6f 776e6564 28267363
> 0024660 h p c _ p - > s c h p c _ m u t
> 6870635f 702d3e73 63687063 5f6d7574
> 0024700 e x ) ) \0 \0 \0 \0 . . / . . / . .
> 65782929 00000000 2e2e2f2e 2e2f2e2e
1493,1494c1493,1494
< 0027240 N U L L \0 \0 \0 . . / . . / . .
< 204e554c 4c000000 2e2e2f2e 2e2f2e2e
---
> 0027240 0 L \0 \0 \0 \0 \0 . . / . . / . .
> 20304c00 00000000 2e2e2f2e 2e2f2e2e
Inspection reveals these to be ASSERT() strings:
ASSERT(MUTEX_HELD(&schpc_p->schpc_mutex));
ASSERT(find_dev->dip == NULL);
So all strings (inside ASSERTs) are being pre-processed, such that the string printed out if/when the assertion fails would not match the one in the assertion (MUTEX_HELD() becomes mutex_owned(), NULL becomes 0, etc). This should be fixed.
Doing a strings(1) on any ELF binaries built from recent (ASSERTION containing) Nevada gate bits reveals this as well.
|
