misson20000 / twili Goto Github PK

It'd be cool to have a twib command to launch a process by Title ID and storage location

Coredumps stream out of twili, but twib tries to buffer them which takes way too much memory for games. Need to stream them through the whole pipeline.

Hi,

Any tips to launch Atmosphere without twili ?

Thank you

Twibd is intended to be a global daemon. It would make sense to put the UNIX socket in /var/run or somewhere similar. The socket location should be configurable via environment variable.

Twib is getting pretty messy. It should be rewriten, or at least massively split up and refactored.

Currently, the terminate command will only work on monitored processes.

1. If PID is a monitored process, use svcTerminateProcess
2. Ask pm:shell to TerminateProcessByPid
3. Use svcTerminateDebugProcess

Blocked on #47.

Currently, every call to printf in Twili blocks on a USB transfer. There should be several different logging modes:

• USB Synchronous: Each call to printf blocks until the data is received by twibd. Useful for debugging.
• USB Asynchronous: When printf is called, if we are waiting on a USB transfer, queue the message and submit another transfer when that one completes. Otherwise, submit a new transfer and don't want for it to complete. Should be more performant than synchronous.
• Transfer: printf appends to a ringbuffer that can be read out via a bridge request. Useful for when USB logging isn't an option, or when it's not important that logs be transferred out-of-band. This mode should never block.

The initial boot is successful, however after sitting on the home menu for a short while (maybe a minute or two?) the following occurs:

Simply having twili installed is sufficient to cause this, no further action required. I've reproduced this on 6.0.0 and 6.2.0.

The PKGBUILD is marked as ISC, despite twib being GPLv3 according to the README.

Wish List

• Implement some tty functions so we can use libraries like linenoise
  • isatty
  • tcgetattr
  • tcsetattr
  • maybe certain ioctls?
• Ctrl-C on twib should terminate target process
  • There should be a command line option to exit without attaching to stdio, and sink stdout/stderr to /dev/null.
  • There should be another twib command to attach to an existing process's stdio
• A process terminating should exit twib

If you invoke LIST_DEVICES on Twibd before it has a chance to do the initial device probe, it will return that no devices are connected.

As an alternative to using twib -d, you should be able to set TWIB_DEVICE_ID to indicate which device should be used.

Thanks to @leoetlino

• System version: 7.0.1
• Atmosphère version: 0.8.6 (2d27dab)
• Twili version: 1.2.0

Steps to reproduce:

1. Connect the Switch to the PC
2. Open twili-gdb
3. Enter target extended-remote | twib -vv gdb
4. Enter attach 0x<pid>

Result:

(gdb) attach 0x8c
Attaching to Remote target
[0][2019-03-31 14:13] tool/GdbConnection.cpp:177: gdb connection got 0xe bytes in
[0][2019-03-31 14:13] tool/GdbStub.cpp:858: got message (0xa bytes)
[0][2019-03-31 14:13] tool/GdbStub.cpp:865: got packet, ident: v
[0][2019-03-31 14:13] tool/GdbStub.cpp:180: got v'Attach'
[0][2019-03-31 14:13] tool/GdbStub.cpp:370: decoded PID: 0x8c
[0][2019-03-31 14:13] tool/SocketClient.cpp:49: sent request
[0][2019-03-31 14:13] platform/unix/platform/EventLoop.cpp:105: event thread notified: '.'
[0][2019-03-31 14:13] common/SocketMessageConnection.cpp:56: pumping out 0x28 bytes
Ignoring packet error, continuing...

At this point, a fatal error shows up on the console (crash_report.txt is the associated crash report)

Second attempt with set debug remote 1:

(gdb) set debug remote 1
(gdb) attach 0x83
Attaching to Remote target
Sending packet: $vAttach;83#71...[0][2019-03-31 14:18] tool/GdbConnection.cpp:177: gdb connection got 0xe bytes in
[0][2019-03-31 14:18] tool/GdbStub.cpp:858: got message (0xa bytes)
[0][2019-03-31 14:18] tool/GdbStub.cpp:865: got packet, ident: v
[0][2019-03-31 14:18] tool/GdbStub.cpp:180: got v'Attach'
[0][2019-03-31 14:18] tool/GdbStub.cpp:370: decoded PID: 0x83
[0][2019-03-31 14:18] tool/SocketClient.cpp:49: sent request
[0][2019-03-31 14:18] platform/unix/platform/EventLoop.cpp:105: event thread notified: '.'
[0][2019-03-31 14:18] common/SocketMessageConnection.cpp:56: pumping out 0x28 bytes
Timed out.
Timed out.
Timed out.
Ignoring packet error, continuing...
Packet vAttach (attach) is supported
Sending packet: $qC#b4...Timed out.
Timed out.

Console crashes with the same fatal error.

https://gist.githubusercontent.com/leoetlino/b75267ecd0eb4b749ee55aa051274a3a/raw/cfbe12d5699092311545e545e1d818ff0d2ad8f3/1_crash_report.txt

Right now, we leak bridge objects all over the place. Here's how I'm thinking to improve it:

• Add a command to close all objects except ID 0. Twibd will invoke this command when it attaches to a device, to clean up any objects that a previous instance of twibd may have left behind.
• Reserve a command ID for closing an object
• Change message format so twibd can keep track of which objects a client owns
• When a client disconnects, have twibd close objects that it left open

• refactor UNIXFrontend and TCPFrontend, move common code to SocketFrontend
• enable/disable frontends on command line
• reduce code duplication between SocketFrontend and Twib
• TCPFrontend should use util::Buffer
• Appveyor/Travis CI for Windows builds

need to run info threads in gdb before doing anything interesting

I have same issue as #55 and I want to compile twili but when I try to run make I get this error:

❯ make                                                                                        3s 908ms
mkdir -p build/twili
/usr/local/Cellar/llvm/6.0.1/bin/clang++ -isystem /Users/xxx/libtransistor_v2.1.1//include/c++/v1/ -g -fPIC -fexceptions -fuse-ld=lld -fstack-protector-strong -O3 -mtune=cortex-a53 -target aarch64-none-linux-gnu -nostdlib -nostdlibinc -isystem /Users/xxx/libtransistor_v2.1.1//include/ -D__SWITCH__=1 -Wno-unused-command-line-argument -std=c++17 -stdlib=libc++ -nodefaultlibs -nostdinc++ -Werror-return-type -Og -Itwili_common -Icommon  -c -o build/twili/twili.o twili/twili.cpp
In file included from twili/twili.cpp:43:
In file included from twili/twili.hpp:28:
In file included from twili/AppletTracker.hpp:27:
twili/process/AppletProcess.hpp:63:7: error: no type named 'KWEvent' in namespace 'trn'; did you mean
      'KEvent'?
        trn::KWEvent command_wevent;
        ~~~~~^~~~~~~
             KEvent
/Users/xxx/libtransistor_v2.1.1//include/libtransistor/cpp/types.hpp:122:7: note:
      'KEvent' declared here
class KEvent : public KWaitable {
      ^
In file included from twili/twili.cpp:43:
In file included from twili/twili.hpp:28:
twili/AppletTracker.hpp:69:7: error: no type named 'KWEvent' in namespace 'trn'; did you mean
      'KEvent'?
        trn::KWEvent process_queued_wevent;
        ~~~~~^~~~~~~
             KEvent
/Users/xxx/libtransistor_v2.1.1//include/libtransistor/cpp/types.hpp:122:7: note:
      'KEvent' declared here
class KEvent : public KWaitable {
      ^
In file included from twili/twili.cpp:43:
In file included from twili/twili.hpp:32:
twili/bridge/tcp/TCPBridge.hpp:25:9: fatal error: 'libtransistor/condvar.h' file not found
#include<libtransistor/condvar.h>
        ^~~~~~~~~~~~~~~~~~~~~~~~~
3 errors generated.
make: *** [build/twili/twili.o] Error 1

❯ echo $LIBTRANSISTOR_HOME
/Users/xxx/libtransistor_v2.1.1/

NIFM seems to signal that a wifi network comes up before routes are properly configured. Possible solutions involve figuring out whether there's a way to get NIFM to signal after routes come up, or delaying the multicast announcement by a few seconds.

This should come after #7.
It'd be cool to be able to have Twili provide virtual filesystems backed by directories on the workstation. There should be a ITwiliService command MountRemoteFilesystem which will return an IFileSystem tunneling operations through to twib.

Make twib accept Twili's USB serial logs, to remove dependency on twik or libtransistor serial driver. Not sure if I should just forward to stdout, or associate logs with a device and have a twib command to retrieve device logs (twib logs -n <lines> for end of log, twib logs -f to follow log). The problem is that we can receive logs before we've identified a device, and that we may want to keep logs around after a device disconnects.

I'm trying to launch homebrew with twib and i got this error :

~/Documents/GameOfLife(master) » twib run -a ./hello.nro                                                                                        segfault42@segfault42-pc
terminate called after throwing an instance of 'twili::twib::ResultError'
  what():  ResultError: 0x6dd
[1]    14707 abort (core dumped)  twib run -a ./hello.nro

Everything is working fine (twib list-devices, ps, identify ...) except twib run.

Switch firmware : 5.1.0

Tested with Atmosphere 0.8.2

Frequently, when attempting to launch a process on 5.0.0, Twili generates this incredibly unhelpful error code.

For things like enabling/disabling USBBridge/TCPBridge, changing TCPBridge port, logging verbosity, whether logging is synchronous (for debugging) or not, path to HBM after #46 is completed, etc.

Twib has a few lessons to learn from adb. Twib should be split into twibd, which will run in the background and handle USB comms, and the twib client which will talk to twibd. twibd will handle multiplexing of i/o streams between applications under Twili and twib client instances.

This issue was generated by todo based on a TODO comment in 2b0ecaa when #59 was merged. cc @misson20000.

It's <INSERT YEAR HERE>! Header file changes should affect the source files that include them!

File transfers over USB would be nice. https://developer.android.com/studio/command-line/adb#copyfiles

Twili uses too much memory on 5.0.0 so we need to raise the limit.

The Twili side of the bridge should be able to handle requests asynchronously, and should also be able to handle dispatching requests to multiple objects.

Twili should provide a creport implementation that submits a request to Twili that will print a message to the console that the given process has crashed and will wait until either twib coredump or twib terminate is invoked.

Now that we have ITwibPipeReader, coredumps should be able to be streamed, instead of having to buffer the whole coredump (potentially in gigabytes) in both twib and twibd's memories before it's written out to disk. We could also show a progress bar I guess?

Currently blocked on #5

Using select is kinda gross, and the various "event thread notification" tricks we pull are even worse. The various event loops in twib/twibd should be refactored to be platform specific and take advantage of each platform's synchronization mechanisms (eventfd for linux, kqueue for osx/bsd, WSAWaitForMultipleEvents for winsock).

Blocked on #17.

The CreateProcess command should return two read pipe objects (stdout, stderr) and a write pipe object (stdin) whose IDs will be sent in the response. The instance of twib that called CreateProcess should read the stdout/stderr pipes, forwarding bytes to its own stdout/stderr, and it should listen on stdin and send bytes from there to the Twili stdin pipe. This way, each process's stdio will be linked to the twib instance that started it.

Look into making Twibd run as a Windows service.

• Write HOWTO guide.
  • Make sure it's easy to get going on Windows.
• Test twib/twibd on Windows.
• Bug squashing
• Test firmware compatiblity.
• Logo?
• Make sure our travis artifacts are working.