Actions
Bug #1702
open
D compiler chokes on some bitfields
Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2011-10-29
Due date:
% Done:
0%
Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:
External Bug:
Description
Using the new print() action, we can see that the D compiler generates incorrect CTF data for some bitfields:
- dtrace -qn 'BEGIN{print(*((D`user_desc_t *)0xffffff00cb413ad0)); exit(0)}'
user_desc_t {
unsigned long usd_lolimit = 0xcff3000000ffff
unsigned long usd_lobase = 0xcff3000000
unsigned long usd_midbase = 0xcff300
unsigned long usd_type = 0xcff3
unsigned long usd_dpl :64 = 0xcff3
unsigned long usd_p :64 = 0xcff3
unsigned long usd_hilimit = 0xcf
unsigned long usd_avl :64 = 0xcf
unsigned long usd_long :64 = 0xcf
unsigned long usd_def32 :64 = 0xcf
unsigned long usd_gran :64 = 0xcf
unsigned long usd_hibase = 0
} - dtrace -qn 'BEGIN{print(*((genunix`user_desc_t *)0xffffff00cb413ad0)); exit(0)}'
user_desc_t {
unsigned long usd_lolimit :16 = 0xffff
unsigned long usd_lobase :16 = 0
unsigned long usd_midbase :8 = 0
unsigned long usd_type :5 = 0x13
unsigned long usd_dpl :2 = 0x3
unsigned long usd_p :1 = 0x1
unsigned long usd_hilimit :4 = 0xf
unsigned long usd_avl :1 = 0
unsigned long usd_long :1 = 0
unsigned long usd_def32 :1 = 0x1
unsigned long usd_gran :1 = 0x1
unsigned long usd_hibase :8 = 0
}
The latter (based on the genunix type) matches the expected value from mdb's ::print.
Updated by Sean Silva almost 11 years ago
This occurs because libdtrace's pseudo-C compiler uses libctf for storing type information, and libctf does not handle bitfields correctly. The offending code is:
http://src.illumos.org/source/xref/illumos-gate/usr/src/common/ctf/ctf_create.c#979
Basically, libctf uses its own rules to decide how bitfields are laid out instead of the rules of the actual ABI.
Actions