Oleg> But what about features? What should I do next? all-stop,
Oleg> thread-specific breakpoints (currently I have no idea what
Oleg> this means), or what?
I think it would be good to implement a feature that shows how this
approach is an improvement over the current state of gdb+ptrace or
gdb+gd
Oleg> Now, to continue the tracee, gdb does not restore the
Oleg> original instruction. Instead, it
Oleg> - writes this insn into _start code
Oleg> - changes regs->ip to point to this insn
Oleg> - does single-step to execute this insn
Oleg> - changes regs
> "Oleg" == Oleg Nesterov writes:
>> I've always just used:
>> (gdb) set var=0
Oleg> No, I tried this too, doesn't work.
Oleg> (gdb) set var=0
Oleg> A syntax error in expression, near `=0'.
Yeah, it is ambiguous if the actual variable name conflicts with any gdb
"set" subcommand.
I typ
> "Oleg" == Oleg Nesterov writes:
Oleg> (gdb) set var 0
You need: set variable var = 0
The "variable" can be abbreviated.
FWIW, "print", "set variable", and "call" are basically aliases.
"print" just happens to print the result of the expression.
Tom
Tom> I made a new branch, 'archer-ugdb'.
Oleg> I assume, you mean git://sourceware.org/git/gdb.git ?
git://sourceware.org/git/archer.git
I can give you write access to this repository if you want.
Just let me know.
Tom
Roland> However, I think the test you probably want is !S_ISCHR.
Thanks. I wasn't sure.
Roland> Actually, better yet, just make it !isatty (fd).
Ok.
I made a new branch, 'archer-ugdb'.
This patch is there. (Actually 2 patches due to me not reading
carefully enough the first time -- but whatev
Roland> I don't really know the gdb code, but I'm surprised it really
Roland> has multiple different "serial" backends.
I don't know this area well, but considering that ser-unix.c is just
chock full of tty-related goo, I think it is probably important for
something. My impression is that this AP
> "Oleg" == Oleg Nesterov writes:
Tom> I looked at this a little bit. It seems to me that the "hardwire" stuff
Tom> is for talking to ttys, and we instead want gdb to be using the pipe code.
Oleg> I didn't verify this, but I don't think so. Please look at pipe_open().
Yeah, I wasn't clear
> "Oleg" == Oleg Nesterov writes:
Oleg> So, the patch below fixes the problem, and gdb + /proc/ugdb seems
Oleg> to work.
Oleg> Indeed, gdb sees that this fd is not pipe/tcp and uses the "hardwire"
Oleg> serial_ops, but hardwire_readchar() doesn't play well with select().
Oleg> Please teach
> "Jan" == Jan Kratochvil writes:
Jan> gdb linux-nat.c (=local gdb) should be deprecated. There is
Jan> definitely a need for remote target and actively maintaining two
Jan> modes is not effective, we can run gdbserver even during
Jan> single-host debugging.
I think we should differentiate
>>>>> "Ananth" == Ananth N Mavinakayanahalli writes:
Ananth> OTOH, the Tom Tromey alluded on lkml that if kernel provides
Ananth> infrastructure that allows for breakpoint assistance and 'displaced'
Ananth> stepping, with a suitable user interface, pr
Tom> * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
Tom> Internally we're already using a self-pipe to integrate this into
Tom> gdb's main loop. Relatedly, don't mess with the inferior's parentage.
Andi> How would having a kernel based solution be better over your
Andi> u
> "Linus" == Linus Torvalds writes:
Tom> * Support "displaced stepping" in the kernel; I think this would improve
Tom> performance when debugging in non-stop mode.
Linus> Don't we already do that at least on x86?
I don't know. If it does, and gdb does not yet use that, then that
would be w
> "Linus" == Linus Torvalds writes:
Linus> No. There is absolutely _no_ reason to believe that gdb et al would ever
Linus> delete the ptrace interfaces anyway.
Yes, in GDB we approximately never delete anything.
Nevertheless, if the Linux kernel were to present a new user-space API,
and i
14 matches
Mail list logo
