> I seem to understand the problem(s). I am a bit surprized. Basically
> I have the questions about almost every utrace_ function. I'll try
> to recheck and summarize my concerns tomorrow with a fresh head, I
> hope I missed something.
Ok. That stuff about pure kernel implementation issues doesn'
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
On 08/13, Tom Tromey wrote:
>
> 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.
Good. IIUC, this also allows to remove the ugly "return 0
to pretend TCGETS/TCSETS/TCFLSH works" from ->
On 08/13, Oleg Nesterov wrote:
>
> As usual, I can't blame my code. I am still investigating, the crash
> is not easy to reproduce, but so far I _suspect_ the problems in utrace
> code. At least utrace_barrier()->signal_pending() is definitely not
> right.
I seem to understand the problem(s). I am
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
On Thu, Aug 12, 2010 at 10:37:18PM -0600, Tom Tromey wrote:
> 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
> 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 API is not just used for target
> communication but also for manipulating gdb's own terminal.
Ah, I see.
> I've app
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
I don't really know the gdb code, but I'm surprised it really has multiple
different "serial" backends. I would have thought that after opening the
fd, you would treat them all about the same. If tcsetattr et al work on
it, then you set the baud rate and whatever, if they say ENOTTY then fine.
It
> "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
10 matches
Mail list logo
