Glitch in ctfconvert

There is a glitch with ctfconvert builds the .SUNW_ctf section. It affects debugging the kernel modules with FBT provider of DTrace. I observe that the CTF sections built for the kernel modules have a problem if module symtab stripped or if the symbol table has symbols reordered. This messes up th

User Space DTrace and dumping function arguments for user space

Can we dump function arguments for user space functions just like for functions in kernel space? Can FBT provider dump arguments for user space functions if we do dtrace -l -f -v? I was DTrace'ing "top" utility, (the "top" utility has both the CTF and the Dwarf debug sections built in the object

Symbols in symtab reordered between module.kld and module.ko?

I am comparing the readelf -s snapshot from module.kld and module.ko for a module build in a cross compiler FreeBSD 10 environment, Do the symbols in symtab get reordered between module.kld and module.ko, as an example readelf -s module.kld we pick 2 symbols 2651: 000b823074 FUNCGLOBAL

Re: ELF symtab and ddbsymtab difference

). Making it un-static helps or avoiding the second level strip helps too.. -- Shrikanth R K On Fri, Dec 7, 2012 at 4:41 AM, Konstantin Belousov wrote: > On Wed, Dec 05, 2012 at 12:13:24PM +0530, Shrikanth Kamath wrote: >> This is regarding the fields in the structure "elf_file_t&

DTrace 32 bit on 64 bit machine?

Can the DTrace user space application compiled as 32 bit app be run on machine with x86_64 kernel I have this DTrace port done for code base based on FreeBSD 6.1, and the app is crashing on the amd64 machine with assert Assertion failed: (fsz > 0), function _libelf_getphdr, file ../../../../src/b

DTrace: Where do we run CTFCONVERT for kernel modules

...meaning, I see the following line in "sys/conf/kmod.mk", but that is a CTFMERGE command. .if defined(MK_CTF) && ${MK_CTF} != "no" ${CTFMERGE} ${CTFFLAGS} -o ${.TARGET} ${OBJS} .endif Where do we run the CTFCONVERT on kernel modules? -- Shrikanth R K ___

DTrace and CTF interpretation

I am facing problem with the CTF interpretation of a member in structure, e.g struct foo { struct bar a; uint32_t b; ... uint32_t prefix[1]; } When converting the above member prefix, I enabled the CTF debugs, here is the o/p DEBUG: die 87324: mem 87636: creating member DEBUG:

Re: DTrace unable to dump typedef'ed argument

huang ambrose >> >> same problem on 8.2-stable >> >> 2011/8/10 Shrikanth Kamath >>> >>> I found this on a FreeBSD 8.1 box... >>> >>> %dtrace -l -f rtalloc_fib -v >>> >>> ... >>> Argument Types >>>      

DTrace unable to dump typedef'ed argument

I found this on a FreeBSD 8.1 box... %dtrace -l -f rtalloc_fib -v ... Argument Types args[0]: struct route * args[1]: (unknown) The function defined in sys/net/route.c: void rtalloc_fib(struct route *ro, u_int fibnum) u_int is typedef unsigned int I checked the ctfdu

[DTrace] DIF DIF_OP_LDUW replaced with DIF_OP_RLDUW

I see the the instruction DIF_OP_LDUW (when observed with the option verbose in script) is getting replaced with a DIF_OP_RLDUW. Maybe this is intentional, but with DIF_OP_RLDUW the check 'dtrace_canstore' fails giving 'CPU_DTRACE_KPRIV' fault for whatever variables I query. * Is this intentional

[DTrace][FreeBSD 6.1] Should a kernel global variable reference land up for validation in dtrace_canstore?

I have the following simple DTrace script % cat fbt_test.d BEGIN { trace(kernel`my_kern_variable); } When I run the script I get the following error dtrace: error on enabled probe ID 1 (ID 1: dtrace:::BEGIN): invalid kernel access in action #1 at DIF offset 4 This is a FreeBSD 6.1 base (

ctfconvert : failed to resolve types

I have a small snippet trying to study ctfconvert... struct abc { int length; int bit; union { char key[0]; char *key_ptr[0]; } keys; }; int main() { int a =1; struct abc member = { 16, 5 }; printf("Sizeof abc structure [%d] \n", sizeof(struct abc)); }

Re: DTrace and CTF data

namically, at runtime when DTrace program is > run. That's why you see it with kgdb on the live kernel once probe has > been installed. > DTrace does not modify your original kernel binary, so you will not > see any probes there. > > --Artem > > > > On Sun, May 30, 2

DTrace and CTF data

I have a query about the FBT provider in DTrace, does FBT provider not need the CTF info for the /kernel binary... I have this observation, when I disassemble say a 'kernel_funtion' , I see the function is not instrumented... (kgdb) disassemble kernel_function Dump of assembler code for function

Re: ctfconvert dependency...

This DTrace wiki page mandates the CTF option when enabling DTrace, http://wiki.freebsd.org/DTrace#head-41e7ce9a981893f126bd67c0eb77f388e2213d9d 2010/3/11 "C. Bergström" > Marius Nünnerich wrote: > >> 2010/3/11 "C. Bergström" : >> >> >>>

Re: ctfconvert dependency...

l, is that correct? 2010/3/11 Marius Nünnerich > 2010/3/11 "C. Bergström" : > > Shrikanth Kamath wrote: > >> > >> Just trying to understand the build dependency for ctfconvert... > >> > >> I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency

ctfconvert dependency...

Just trying to understand the build dependency for ctfconvert... I see ctfconvert (cddl/usr.bin/ctfconvert/) has dependency on libctf.a (cddl/lib/libctf/) Now the snippet in bsd.lib.mk has this check for various target suffixes, .c.So: .if defined(CTFCONVERT) ${CTFCONVERT} ${CTFFLAGS} $

Ktrace'ing kernel threads

Can ktrace trace another kernel thread which has roughly the semantics as below, right now it does not hit any of the designated interesting points that ktrace is built for, but what if I could define those, will ktrace still allow tracing another kernel thread? thread(client_info) { ... .