On Mon, Mar 09, 2009 at 01:11:27PM -0700, Eric Schrock wrote:
> What did you decide to do about walk variables? For example:
>
> ::walk foo f | ..
>
> In this case, is 'f' the name of the variable where I want to store the
> walk result, or is it an argument
What did you decide to do about walk variables? For example:
::walk foo f | ..
In this case, is 'f' the name of the variable where I want to store the
walk result, or is it an argument to "::walk foo"? Is there a way to
force it to be one or the other?
- E
> Michelle Olson
> > OGB Secretary
>
> MDB community,
>
> Please vote on renew existing CC list. If there are new people
> who wish to be added please propose.
+1 from me.
- Eric
--
Eric Schrock, Fishworkshttp://blogs.sun.com/eschrock
> Thanks
> -- scott
> http://blogs.sun.com/sdaven
> ___
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Fishworkshttp://blogs.sun.com/eschrock
ly accessed from the
> scripting language.
>
> This project will allow to write new MDB commands using scripting
> languages
> instead of having to write and compile a C module. Thus this will greatly
> reduce the time to write new MDB commands.
>
>
caller or stack output?
>
> Peter
> _______
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
F data
available to print structures. It was sitting on disk, but there was no
way to tell MDB to load it. There are definitely some powerful things
you are doing that will be useful to developers. The mdb fanatics
among us are definitely hoping you'll continue your work.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
u should
have if you are building ON sources. If you're building from the
Mercurial sources I'm not sure how it works since I'm still using
teamware. You may want to ask tools-discuss if it isn't obvious.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
to work would be quite a
challenge (but extremely cool).
Anyway, what you have now is sounds interesting, it'd be cool to see a
webrev of what you have so far.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
any case, thanks for at least prototyping this.
>
> -Mike
>
> --
> Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
> ___
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
ased on this. For the '/' operator, you can find this check in
print_arglist():
if (DCMD_HDRSPEC(flags) && (flags & DCMD_PIPE_OUT) == 0) {
Are you just curious, or are you trying to solve a particular problem?
As Jonathan mentioned, there are more efficient ways to a
ression, and
> it contains the address of the first entry in array, so I would expect
> it will break the pineline, but instead, it works fine. I am somehow
> puzzled about this. Could you give me some hint on this?
> Another question is why the output of /Kn and ::eval Basically I think the output should be the same as they each takes an
> address and dump the content one line a time.
>
> Thanks again,
> Zhijun
>
>
>
>
> ___
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
uot;struct vnode *" 0t2048 p |/Kn |::grep . != 0x1234
> sh: =: not found
>
> Best,
> Zhijun
Yes, that is correct, I misquoted the behavior originally. Everything
after the '!' is passed verbatim to the shell. For the gory details,
see usr/src/cmd/mdb/common/mdb/mdb_
!' character is a metacharacter that opens a pipe to an external
shell command, so if you don't include the quotes it will try to spawn
the program '0x1234' and pipe the output to it.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
gt; true leaks. But I could no longer find the weblog or document
> I read.
>
> Is this something we should be concerned with ? If so, how do
> we go about root-causing it ?
>
> Thanks,
> Michen
>
> ___
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
+ 266
> 08075449 main (2, 80470f0, 80470fc) + f29
> 0805ae0e (2, 804727c, 8047280, 0, 804728a, 804729c)
>
>
> This message posted from opensolaris.org
> ___
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
ng dummy.o
This works for me using /usr/sfw/bin/gcc on my system, which is "gcc
(GCC) 3.4.3 (csl-sol210-3_4-20050802)". ctfconvert groks DWARF
debugging information, so most likely you need to coax your version of
GCC into generating DWARF with:
# gcc -D_KERNEL -c -gdwar
ng). If you use
the mdb dcmd version (::bp), it will rightly complain that no address
was given:
$ mdb
> 5=K
5
> ::bp
Usage: [address]::bp [+/-dDestT] [-c cmd] [-n count] sym ...
mdb: try '::help bp' for more information
> 5::bp
>
Hope that helps.
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
_t v_path
> v_path = 0x85195cf8 "/export/share/tc/C/pipe/pipe.file"
Yes, for this particular case you may have been OK with just truss (to
get the file descriptor being read from) and pfiles (which displays the
path information). But MDB is a handy tool to have around ;-)
- Eric
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
t kthread_t contains at t_pcb[1] the pointer to that
> thread's stack.
You may want to take advantage of the more stable (and semantically
significant) '::walk thread', which takes an optional proc_t parameter:
> 0t711::pid2proc | ::walk thread | ::findstack -v
- Eric
--
x27;: unknown dcmd name
::kmem_verify is a kernel dcmd. For userland, you want '::umem_verify'.
For a list a commands provided by libumem, try '::dmods -l libumem'.
Jonathan or someone other than me can probably explain how libumem's
oversize (mmap) leak detection works.
ks
>
>
> Adam
>
> --
> Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
> ___
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
kup+0x120(147b4, 2b1b8, 0, ffbff798, 0, 26400)
> fmdump_nvl2str+0x54(2b148, 13, 0, ffbff804, 130, 14400)
> flt_verb1+0xcc(268b0, ffbff878, 26548, 14400, 0, 0)
> libfmd_log.so.1`fmd_log_xiter+0x1a0(268b0, 29bf8, 1, 0, 12f88, 11970)
> main+0x7f4(0, 13d34, 268b0, 0, 1, ffbff910)
> _start+0x108(0, 0, 0, 0, 0, 0)
>
> Gavin
> ___
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
option to always push
arguments to the stack a la 32-bit x86, as well as the associated MDB
changes to grab this information. This will be available soon. We're
also working on a programmatic method of disassembling the text and
deriving the original arguments.
In the meantime, you'
a doc bug.
> I'll also log an rfe for a more descriptive help message
> on ::getenv.
The help message would be a useful addition, and a nice oss-bite-size
RFE.
- Eric
--
Eric Schrock, Solaris Kernel Development.
laris.org
> _______
> mdb-discuss mailing list
> mdb-discuss at opensolaris.org
--
Eric Schrock, Solaris Kernel Development.
26 matches
Mail list logo
