On 09/05/18(Wed) 12:13, Artturi Alm wrote:
> On Wed, May 09, 2018 at 10:23:41AM +0200, Martin Pieuchot wrote:
> > On 09/05/18(Wed) 07:48, Artturi Alm wrote:
> > > On Tue, May 08, 2018 at 01:44:39AM +0300, Artturi Alm wrote:
> >
> >
> > No bug are irrelevant to fix. But working with you is hard, really
> > hard. You never explain what the problem is. Reading your email is
> > an exercise in frustration because you can do some good work but you
> > fail to communicate.
> >
> > > > (manual "copypaste"):
> > > > nc2k4hp# sysctl ddb.trigger=1
> > > > Stopped at db_enter+0x4: popl %ebp
> > > > ddb{0}> print/x "eax = " $eax "\necx = " $ecx "\n"
> > > > 3
> > > > ddb{0}> c
> > > > ddb.trigger: 0 -> 1
> > > >
> > > > so, for reasons yet unknown to me, p[rint] doesn't seem to work at all
> > > > like described in the man page, tested on i386.
> >
> > What do no work? What does the man page describe? Do you expect us to
> > read the man page, then look at your mail again, then try to understand
> > what is not working?
> >
>
> For example,
>
> print/x "eax = " $eax "\necx = " $ecx "\n"
>
> will print something like this:
>
> eax = xxxxxx
> ecx = yyyyyy
>
> Now I did install 5.0 into a VM, and there the result for above example
> would of have been just "Ambiguous", and I'm guessing now that this
> has not been working as in the example since import.
> My fix is limited to producing output just like in the example, but
> input requires more, as it needs escapes for everything not a-z,A-Z,0-9.
>
> > > > Should it work? I hope it would.
> >
> > What should work? Why do you hope? Maybe the manpage should be fixed?
> >
>
> Multiple [addr] arguments to p[rint], including support for strings,
> and i hope so because i would find it useful while testing/writing/porting
> drivers. Maybe, I do like "show struct", and have more than just
> the filtering diff for it, but it doesn't really work for the ad hoc
> usecases p[rint] seems so excellent for.
>
> > > Does feel like waste of time to go any further fixing this, if this is
> > > yet another bug too irrelevant for anyone to ack for, so _any_ input
> > > here would be great.
> >
> > Like I said, no bug are irrelevant but if the one finding the bug, you
> > in that case, is not willing to properly explain the problem, then
> > better not send an email at all ;)
>
> Will try in the future.
Thanks for the explanation!
> haven't tested the diff below yet, but compared to previous, it should
> have working /modifierS.
IMHO we should just amend the man page and keep ddb(4) code simple.
