This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

__builtin_return_address usage analysis


One of my ARs from yesterday's call was:
4. Jim: Is __builtin_return_address() used for anything vital?

The short answer is no.  Further analysis below; raw notes after that.

Jim

__builtin_return_address(0) yields the address to which the current
function will return.  __builtin_return_address(1) yields the address to
which the caller will return, and so on up the stack.

Return probes operates by replacing the return address in the stack (or
in a known register, such as the lr register for ppc).  This may cause
__builtin_return_address(0), when invoked from return-probed function,
to return the address of the return-probes trampoline.  There has been
concern that this will break something.

As far as I can tell, __builtin_return_address is used entirely for
tracing (tracing that is disabled by default), profiling, and error
reporting.  I couldn't find any case where normal operation of the OS
would be affected.  In all cases, the trace/profile/error data would
simply report the wrong caller IP.  It would be a case of being
(temporarily) less helpful in the original instrumentation in order to
be more helpful with kprobes/SystemTap.

This should be no problem for kprobes users, since it's easy to verify
(by looking at the source) whether the function you want to probe uses
__builtin_return_address.*  It may be more mystifying for the non-expert
SystemTap user, but such a user would probably not be poring over the
kind of instrumentation output that would be tainted in this way.  Cases
where a return probe will mess up some other instrumentation should be
described in a tapset's documentation.

*__builtin_return_address is used in a few macros.  Grep for #define
below.

Here are some interesting (relative speaking) cases:

- The profiling done by schedule() would give bad data if you probed
returns from schedule().

- A return address shows up in two structures (on different
architectures) dumped by kgdb.

- The perfctr driver would give bad data if certain functions were
probed.

- fs/resiser4 uses it extensively for debug-mode tracing.  This appears
to be the only subsystem that calls __builtin_return_address with an arg
other than 0.

- fs/xfs uses __builtin_return_address extensively for tracing/error
reporting.

RAW NOTES:
136 lines in cscope
arch/alpha/kernel/irq.c
arch/alpha/kernel/pci_iommu.c
arch/alpha/kernel/semaphore.c
arch/alpha/kernel/smp.c
arch/arm/kernel/irq.c
arch/arm/kernel/traps.c
arch/arm/nwfpe/fpmodule.c
arch/arm26/kernel/irq.c
arch/arm26/kernel/traps.c
arch/arm26/mm/small_page.c
arch/arm26/nwfpe/fpmodule.c
arch/frv/kernel/irq.c
arch/i386/kernel/kgdb_stub.c	struct kgdb_info.called_from
arch/m68k/atari/stram.c
arch/m68k/mm/memory.c
arch/parisc/kernel/pci-dma.c
arch/parisc/kernel/traps.c
arch/parisc/lib/debuglocks.c
arch/ppc/lib/locks.c
arch/ppc/mm/pgtable.c
arch/ppc64/kernel/pmc.c
arch/s390/kernel/debug.c
arch/sh/boards/renesas/edosk7705/io.c
arch/sh/boards/renesas/hs7751rvoip/io.c
arch/sh/boards/renesas/rts7751r2d/io.c
arch/sh/boards/renesas/systemh/io.c
arch/sh/boards/se/770x/io.c
arch/sh/boards/se/7751/io.c
arch/sh/boards/snapgear/io.c
arch/sparc/mm/srmmu.c
arch/sparc64/kernel/pci_iommu.c
arch/v850/kernel/irq.c
arch/x86_64/kernel/i8259.c
arch/x86_64/kernel/kgdb_stub.c	Also struct kgdb_and_then_struct.from
arch/x86_64/kernel/pci-gart.c
arch/x86_64/kernel/ptrace.c
arch/x86_64/kernel/signal.c
drivers/parisc/superio.c
drivers/perfctr/x86.c
	See calls to redirect_call
drivers/s390/s390mach.c
	s390_handle_damage, called from s390_do_machine_check
drivers/scsi/arm/fas216.c
drivers/usb/gadget/serial.c		Calls 3x with 0, 1, 2.
fs/compat.c
fs/hfs/bfind.c
fs/hfsplus/bfind.c
fs/reiser4/block_alloc.c		Calls 4x with 0, 1, 2, 3.
	reiser4_context.grabbed_at[4] if REISER4_DEBUG.  Never refed.
fs/reiser4/debug.c			Calls 5x with 0-4.
	reiser4_context.err.bt[5] if REISER4_DEBUG.
fs/reiser4/inode.c			Calls 4x with 0-3
	reiser4_context.dirty.stack[4] if REISER4_DEBUG.
fs/reiser4/plugin/file/tail_conversion.c	Calls 5x with 0-4.
	unix_file_info_t.where[5] if REISER4_DEBUG.
fs/reiser4/seal.c			Calls 5x with 0-4.
	seal_t.bt[5] if REISER4_DEBUG.
fs/reiser4/status_flags.c		Calls 10x with 0-9.
	reiser4_status.stacktrace[10]	Called for panics and such.
fs/xfs/linux-2.6/xfs_buf.c
	Used in calls to pagebuf_trace, e.g., from PB_TRACE (called 27x)
	and xfs_buftrace (called 32x).  Defined ifdef PAGEBUF_TRACE.
fs/xfs/linux-2.6/xfs_buf.h		See above.
fs/xfs/linux-2.6/xfs_linux.h
	#define __return_address __builtin_return_address(0)
	~60 refs to __return_address in calls to vn_trace_entry/exit/etc,
	__xfs_dqtrace_entry, xfs_ilock_trace.
	Also, KTRACE_ENTER (fs/xfs/linux-2.6/xfs_vnode.c - called 5x)
	refs __return_address.  (KTRACE_ENTER defined ifdef XFS_VNODE_TRACE)
	Also much stuff around XFS_DABUF_DEBUG, XFS_ERROR_REPORT.
include/asm-frv/system.h	thread.sched_lr used only by show_trace_task
include/asm-i386/spinlock.h
include/asm-m32r/spinlock.h
include/asm-mips/processor.h
	#define return_address() ({__asm__
__volatile__("":::"$31");__builtin_return_address(0);} -- unused
include/asm-parisc/spinlock.h
include/asm-x86_64/spinlock.h
include/linux/skbuff.h
	#define NET_CALLER(arg) __builtin_return_address(0)
	NET_CALLER just in printks
kernel/panic.c
	CONFIG_ARCH_S390 only -- passed to disabled_wait() by panic()
kernel/sched.c
	schedule() passes to profile_hit() -- profiling
kernel/timer.c
lib/kernel_lock.c
mm/slab.c
	cache_alloc_debugcheck_after used ifdef CONFIG_DEBUG_PAGEALLOC
	cache_free_debugcheck used if DEBUG
net/ipv4/ipvs/ip_vs_conn.c
net/ipv4/ipvs/ip_vs_ctl.c
net/ipv4/ipvs/ip_vs_lblc.c
net/ipv4/ipvs/ip_vs_lblcr.c
sound/core/device.c
sound/core/memalloc.c
sound/core/memory.c
	#define _snd_kmalloc(size, flags) __snd_kmalloc((size), (flags),
__builtin_return_address(0));
	struct snd_alloc_track defined if CONFIG_SND_DEBUG_MEMORY




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]