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.
