This was found on an old openbsd kernel image that Leonardo Chiquito built
enabling DWARF instead of the default, STABS debugging format 8)
Just this struct has this characteristic:
struct ricoh_is410_window_data {
struct scsi_window_data window_data; /* 0 48 */
u_int8_t res1; /* 48 1 */
u_int8_t res2; /* 49 1 */
/* Bitfield combined with previous fields */
u_int mrif:1; /* 48:15 4 */
u_int filtering:3; /* 48:12 4 */
u_int gamma_id:4; /* 48: 8 4 */
/* size: 52, cachelines: 1 */
/* bit_padding: 24 bits */
/* last cacheline: 52 bytes */
};
Now there are no BRAIN FART ALERT!s when paholing openbsd, yay!
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Lots of BRAIN FART ALERT!s removed!
There is still a problem in class__find_holes where we don't catch bitfields
that are combined with previous fields where the byte offset for the bitfield
is the same as the previous field. This happens when the compiler combines a
bitfield with real byte size > 1 just after a one or two bytes field that is at
an alignment boundary.
Will fix later.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Make class__find_holes understand that when a byte offset goes backward it is
because the compiler is "combining" small bitfields with previous fields, and
using from the end of the combined bitfield + small fields. This made your
head hurt, huh? One example:
struct usb_bus {
struct device * controller; /* 0 8 */
int busnum; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
char * bus_name; /* 16 8 */
u8 uses_dma; /* 24 1 */
u8 otg_port; /* 25 1 */
/* Bitfield combined with previous fields */
unsigned int is_b_host:1; /* 24:15 4 */
unsigned int b_hnp_enable:1; /* 24:14 4 */
/* XXX 14 bits hole, try to pack */
int devnum_next; /* 28 4 */
struct usb_devmap devmap; /* 32 16 */
<SNIP>
};
See? is_b_host:1 .. b_hnp_enable:1 makes a bitfield of just two bits.
The programmer decided to make this a 'unsigned int' bitfield, so taking 4 bytes.
And placed this "4" bytes bitfield just after two fields of one byte.
The compiler put the "4" bytes bitfield "in the same place" as the "uses_dma"
field, but its really not clobbering it neither "otg_port", as it allocates it
from (offset 24 + sizeof(unsigned int) - 1), backwards.
So at the end there is a, now correctly calculated, 14 bits hole, and that
matches the bit offset used for the last field, that is "14", as offsets for
bits and bytes starts at zero, all is explained now.
One last thing is that since we actually have 14 bits we in fact have a one
byte hole + a 6 bits hole, but that should be clear (haha) for those looking
for holes :-)
Nah, just run pahole reorganize on this beast and you'll have (for the complete
structure, with the <SNIP> part back in:
struct usb_bus {
struct device * controller; /* 0 8 */
int busnum; /* 8 4 */
unsigned char is_b_host:1; /* 12:247 1 */
unsigned char b_hnp_enable:1; /* 12:246 1 */
/* XXX 6 bits hole, try to pack */
u8 otg_port; /* 13 1 */
u8 uses_dma; /* 14 1 */
/* XXX 1 byte hole, try to pack */
char * bus_name; /* 16 8 */
int bandwidth_isoc_reqs; /* 24 4 */
int devnum_next; /* 28 4 */
struct usb_devmap devmap; /* 32 16 */
struct usb_device * root_hub; /* 48 8 */
struct list_head bus_list; /* 56 16 */
/* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
int bandwidth_allocated; /* 72 4 */
int bandwidth_int_reqs; /* 76 4 */
struct dentry * usbfs_dentry; /* 80 8 */
struct class_device * class_dev; /* 88 8 */
struct mon_bus * mon_bus; /* 96 8 */
int monitored; /* 104 4 */
/* size: 112, cachelines: 2 */
/* sum members: 107, holes: 1, sum holes: 1 */
/* bit holes: 1, sum bit holes: 6 bits */
/* padding: 4 */
/* last cacheline: 48 bytes */
}; /* saved 8 bytes! */
And we save 8 bytes and reduce the previous complexity. Hey, but look at those
bit offsets at is_b_host and b_hnp_enable... damn, exposing the bit offsets I
just exposed another bug, that is: the reorganization code is not fixing up the
bit offsets, one more for the TODO list, nah, just compile it and pass the
results back to the dwarves and we get:
struct usb_bus {
struct device * controller; /* 0 8 */
int busnum; /* 8 4 */
unsigned char is_b_host:1; /* 12: 7 1 */
unsigned char b_hnp_enable:1; /* 12: 6 1 */
/* XXX 6 bits hole, try to pack */
u8 otg_port; /* 13 1 */
u8 uses_dma; /* 14 1 */
/* XXX 1 byte hole, try to pack */
char * bus_name; /* 16 8 */
int bandwidth_isoc_reqs; /* 24 4 */
int devnum_next; /* 28 4 */
struct usb_devmap devmap; /* 32 16 */
struct usb_device * root_hub; /* 48 8 */
struct list_head bus_list; /* 56 16 */
/* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */
int bandwidth_allocated; /* 72 4 */
int bandwidth_int_reqs; /* 76 4 */
struct dentry * usbfs_dentry; /* 80 8 */
struct class_device * class_dev; /* 88 8 */
struct mon_bus * mon_bus; /* 96 8 */
int monitored; /* 104 4 */
/* size: 112, cachelines: 2 */
/* sum members: 107, holes: 1, sum holes: 1 */
/* bit holes: 1, sum bit holes: 6 bits */
/* padding: 4 */
/* last cacheline: 48 bytes */
};
See? this time gcc fixed up things for us and even agreed on the reorganization
the dwarves did! 8-)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Helps understanding how bitfields really work, and after all it is just
confusing, not wrong.
See this one:
struct usb_bus {
struct device * controller; /* 0 8 */
int busnum; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
char * bus_name; /* 16 8 */
u8 uses_dma; /* 24 1 */
u8 otg_port; /* 25 1 */
/* WARNING: DWARF offset=24, real offset=26 */
unsigned int is_b_host:1; /* 24:15 4 */
unsigned int b_hnp_enable:1; /* 24:14 4 */
/* XXX 30 bits hole, try to pack */
int devnum_next; /* 28 4 */
<SNIP>
};
So the bitfield _really_ is at offset 24 and the "WARNING:" above is just
pahole not understanding how it works, i.e. it starts at 24 and since the
bitfield has a 'unsigned int' as its base type it goes from 24 to 27, the
offsets start at the end, i.e. from byte 27 back to byte 27, but as only two
bits are used, it puts bit padding at the end, at bit offset 0, that is the
last bit in byte 27 and uses the first bits of byte 26 at bit offset 14 and 15.
Now to make libdwarves finally understand this convention.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This struct, from the linux kernel:
struct usb_bus {
struct device * controller; /* 0 8 */
int busnum; /* 8 4 */
char * bus_name; /* 16 8 */
u8 uses_dma; /* 24 1 */
u8 otg_port; /* 25 1 */
unsigned int is_b_host:1; /* 24 4 */
unsigned int b_hnp_enable:1; /* 24 4 */
int devnum_next; /* 28 4 */
struct usb_devmap devmap; /* 32 16 */
struct usb_device * root_hub; /* 48 8 */
struct list_head bus_list; /* 56 16 */
int bandwidth_allocated; /* 72 4 */
int bandwidth_int_reqs; /* 76 4 */
int bandwidth_isoc_reqs; /* 80 4 */
struct dentry * usbfs_dentry; /* 88 8 */
struct class_device * class_dev; /* 96 8 */
struct mon_bus * mon_bus; /* 104 8 */
int monitored; /* 112 4 */
};
Generates seemingly wrong DWARF when compiled with GCC:
struct usb_bus {
struct device * controller; /* 0 8 */
int busnum; /* 8 4 */
/* XXX 4 bytes hole, try to pack */
char * bus_name; /* 16 8 */
u8 uses_dma; /* 24 1 */
u8 otg_port; /* 25 1 */
/* WARNING: DWARF offset=24, real offset=26 */
unsigned int is_b_host:1; /* 24 4 */
unsigned int b_hnp_enable:1; /* 24 4 */
/* XXX 30 bits hole, try to pack */
int devnum_next; /* 28 4 */
struct usb_devmap devmap; /* 32 16 */
struct usb_device * root_hub; /* 48 8 */
struct list_head bus_list; /* 56 16 */
/* --- cacheline 1 boundary (64 bytes) was 10 bytes ago --- */
int bandwidth_allocated; /* 72 4 */
int bandwidth_int_reqs; /* 76 4 */
int bandwidth_isoc_reqs; /* 80 4 */
/* XXX 4 bytes hole, try to pack */
struct dentry * usbfs_dentry; /* 88 8 */
struct class_device * class_dev; /* 96 8 */
struct mon_bus * mon_bus; /* 104 8 */
int monitored; /* 112 4 */
/* size: 120, cachelines: 2 */
/* sum members: 110, holes: 2, sum holes: 8 */
/* bit holes: 1, sum bit holes: 30 bits */
/* padding: 4 */
/* last cacheline: 56 bytes */
/* BRAIN FART ALERT! 120 != 110 + 8(holes), diff = 2 */
};
Look at the offset for the first entry in the bitfield (is_b_host), the
compiler said in the DWARF info that it was at offset 25, when in fact it is at
offset 26 as can be seen when looking at the generated assembly code.
This previously was confusing libdwarves, as it uses subtracts the last offset
from the current offset to see what was the size the compiler really allocated
to then check if it is equal to the size of the previous entry, so as to detect
alignment holes.
The offsets are uint32_t, so cast both to int64_t when doing the calculation,
the existing code already deals with negative numbers that result in this
patologic case.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This is used to let cmake know that's only C project, and it shouldn't check
for C++ compiler - shrinks the build requirements ;)
+INCLUDE_DIRECTORIES( ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR} )
This one allows to make out of sourcetree builds...
Signed-off-by: Daniel Gollub <dgollub@suse.de>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Now that ctracer generates systemtap scripts lets drop this file, its
misleading for casual readers.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In the Linux kernel, currently the only target, we can't probe the
functions in kernel/{kprobe,relay}.c.
When systemtap starts supporting uprobes, there may be other cases that
require blacklisting CUs.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
I.e. now we use this systemtap syntax:
probe mtrr_write = kernel.function("mtrr_write@arch/i386/kernel/cpu/mtrr/if.c")
mtrr_write is the function, followed by @ and then the CU, i.e. the source for
the object file (CU) where the function is.
This way we can support global namespace clashes.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
A pointer class is one that has as one of its members a pointer to the target class,
example:
target class: sock
pointer classes: sk_buff, socket
Because struct sk_buff and struct socket has members that are pointers to a struct sock.
This way we can follow all the struct socket and struct sk_buff methods and pass to
the struct sock collector as $skb->sk, for instance.
With this we now go all the way from the socket layer to the sk_buff layer, passing thru
the sock layer.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
In ctracer we can find a function that receives as one of its arguments a
pointer to the target class and also a pointer to an alias or pointer class,
so we have to check if the function was already added to one of these lists:
class methods list
class aliases list
class pointer list
To avoid corrupting one of them by trying to add the function to multiple
lists.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To find members that are pointers to the specified class:
[acme@tab pahole]$ pahole -f sock /usr/lib/debug/lib/modules/2.6.23.1-49.fc8/vmlinux
tcp_iter_state: syn_wait_sk
ip_ra_chain: sk
netlink_set_err_data: exclude_sk
netlink_broadcast_data: exclude_sk
cn_dev: nls
cn_callback_entry: nls
cn_queue_dev: nls
sk_security_struct: sk
unix_sock: peer
unix_sock: other
request_sock: sk
mqueue_inode_info: notify_sock
sock_iocb: sk
socket: sk
sk_buff: sk
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When we are looking for members of some type in all CUs it may be that in
some CU we don't have the full type, but just a declaration.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Definition of a class alias:
A class that has as its first member a member that is of the type searched.
Example:
struct tcp6_sock {
struct tcp_sock {
struct inet_connection_sock {
struct inet_sock {
struct sock {
}
}
}
}
}
So tcp6_sock, tcp_sock, inet_connection_sock, inet_sock are aliases for sock.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
At that point we are emitting the definitions for the member types,
so we have to print a newline after each.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
systemtap represents this as uint64_t, casting this to (void *) is not
allowed by the compiler, and as we know that this _is_ a pointer going thru
hops in systemtap, cast it back to (long) that will make this work on both
64 and 32 bit arches as sizeof(long) = sizeof(void *).
Fugly, have to learn more about systemtap internals...
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Now that we keep base type typedefs we need their definition in both the ostra
converter and the kernel collector, so moving them to a separate file and
including gets us the typedef definitions.
This paves the way for atomic_t and other types being also collected, once I
get some pluggable data dictionary definiton on how to collect non-base types
to avoid making all of ctracer kernel specific.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If some previous step did something wrong and left padding on a struct that the
compiler will not generate padding, fix it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
If the member size is equal to the power2 being looked up we have to
break the loop, no need to look at the smaller powers of 2.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
But don't stare at it for too long, your head will hurt. At least now it
generates a correct struct ctracer__mini_file, the linux kernel struct file
view with just the base types.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Its not really being used right now, but for simplification, if we even ask
for bitfields to be removed, just do it in a group.
class__remove_member needs an overhaul, to handle things like bubbling up
bitfields when one of its entries is removed.
class_member__bitfield_tail seems to be solid and should be considered to be
used when moving bitfields around in dwarves_reorganize.c.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
a <-> b <-> c <-> d <-> e <-> f <-> g
list_del_range(b, d) turns the list into:
a <-> e <-> f <-> g
This one is not in the kernel list.h, have to look if there are uses and push
it to linux if there are any.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Changed from fputs to fprintf and didn't scaped the % that should
be in the c source file generated, duh.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo Carvalho de Melo
Daniel Gollub