Don't worry about looking at the latest yet -- there are still a number of improvements to be made.
On Fri, Aug 12, 2016, 11:55 Barret Rhoden <[email protected]> wrote: > On 2016-08-12 at 10:54 "'Christopher Koch' via Akaros" > > > Does the server side currently have similar limitations? > > > > > > > No, though it doesn't matter much for the server -- under the current > > assumptions made, the server will only be sent one request at a time. > > It is however possible to send multiple requests to the 2LS and get > > multiple responses if one were to write a different client. > > Glad to hear it. Eventually I'd like to use this infrastructure for > more than just GDB, and having the server be able to deal with > concurrent requests is a part of that. > > > > > + /* Set d9 ops. */ > > > > + d9_ops = dops; > > > > > > Are we ever going to change d9_ops at runtime? I noticed down in > > > uthread_2ls_init() that you dynamically set the values for dops, > > > then here we assign it to d9_ops. My guess is this never changes, > > > (i.e. no specific 2LS will override them), so we can just set up > > > d9_ops statically. > > > > > > > Actually, yes, specific 2LS' should have the ability to override these > > operations. For example, for the VM 2LS, I'll have a separate > > read_memory and write_memory that convert the address from guest > > virtual to host virtual. > > I'm not sure of that example. I don't know if we can debug both the > guest and the host at the same time, and if we are debugging the guest, > that would prevent the guest kernel from debugging itself. We'd also > need read_memory() to know which thread it is talking about: host > thread or guest thread. > > Anyway, I'm OK with leave the d9_ops as-is for now. > > > > > When are these srv files removed? After running for a bit, do you > > > have a large number of srv files (one for every process that ever > > > existed)? We probably can deal with this with the #proc file in the > > > future. > > > > > > > They aren't currently :( I hadn't thought of that. Should I do the > > #proc file first? > > Maybe. I'm trying to think of another mitigation, other than "don't > worry about it - usually people reboot a lot", but nothing is coming to > mind. If you can fix it now, that'd be great. If it's a pain, I'm OK > with doing it soon after committing these patches. > > > > > Given the type, it seems like you usually know the pck_len. Other > > > than D9_RREADMEM, the other callers are all passing in a static > > > value. Is there a reasonable limit to the size of the readlen? > > > For instance, can we tell GDB that PacketSize=1024 or something? > > > > > > > RREADMEM and TSTOREMEM (which isn't part of this yet I think). > > There currently isn't, because I don't know what the max gdb will ask > > for is. (I'll think about this some more.) > > Sounds good. I glanced around a little and stumbled on PacketSize. It > looks like there's a feature negotiation phase between gdb and > gdbserver, and the gdbserver can respond with a static limit on these > sizes. Maybe. =) > > > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#General-Query-Packets > > (grep PacketSize and qSupported) > > > > > > + return_packet_size = sizeof(struct d9_header) + length; > > > > + char pkt_buf[return_packet_size]; > > > > > > Depending on the size of return_packet_size, this might be a little > > > dangerous. A lot of our 2LSs have a limit to the stacksize. For > > > pthreads, which gdbserver uses, it is currently 4MB. How big are > > > these return packets? > > > > > > > So far, the largest that I've seen by observation is 64 bytes for a > > read memory or store memory request, and the register packets are > > larger (208, I think). I think it'd be useful to impose an upper > > limit at some point, but with how I just rewrote things, there is > > none. The messages that have dynamic size are on the heap, most of > > the others are on the stack and <= 208 bytes. > > If we limit packet sizes to 256, then I think we'd be safe using the > stack for pkt_buf. > > > > > > + d9_server_init(ops, &d9ops); > > > > > > It might be better to do this at the end of uthread_lib_init(), > > > instead of in uthread_2ls_init. (More syscall and event > > > infrastructure is set up). And you probably don't need the d9ops > > > stuff in uthread.c at all. > > > > > > > I don't remember quite what the reason was, but I wanted this to be > > done before we changed contexts. (I should have written down what the > > bug was...) Anyway, this was moved slightly in the next commit > > anyway, so I moved it here, too. > > Maybe it was so that the init happened before init_posix_signals? Just > guessing there. > > The main thing is that if you do it too early (before scp_vcctx_ready() > and setting blockon), you might get weird behavior when it comes to > blocking syscalls and event delivery. Before that call, the kernel > (and glibc, IIRC) will treat processes as if they can't handle events > and blocking on their own. If some problem in that area arises, then > we can deal with it later. > > > I haven't looked at your latest changes yet. I'll get to that at some > point. > > Barret > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Christopher Koch | Software Engineer | [email protected] | 650-214-3546 -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
