Cześć
debugguje zdalnie projekt na linuxie za pomocą visual studio. Chciałbym zrobić sobie tymczasowe logi, które będą wyświetlane w Outpucie w tym IDE. syslog(3) nie działa, bo nie wyświetla w outpucie a tego potrzebuje. Pytanie czy w ogóle da się coś takiego zrobić? Jeżeli tak to czy jest jakaś funkcja pokroju właśnie "OutputDebugString" do tego?
Ogólnie: nie, nie da się, przynajmniej nie w prosty sposób. Co możesz zrobić to testować na obecność debugera i wtedy printować lub nie; będzie to drogie i raczej ciężkie, ale powinno zadziałać (forkujesz proces i próbujesz zrobić ptrace-attach do parenta - jak nie zadziała, to wiesz, że już ktoś debuguje).
Tzn. nie wiem czy problemem jest dla Ciebie testowanie na obecność debugera w systemie, czy może fakt, że robisz "attach" do działającego procesu, albo po prostu wygoda otwarcia jednego okienka. Detale tu:
https://stackoverflow.com/a/3599394/4885321
EDIT: ale żeby była jasność: wprost do gdb stringa raczej nie przekażesz.
Pierwszy raz widzę coś takiego jak OutputDebugString, ale wnioskując po samej nazwie wnioskuję że służy to do printowania komunikatów do debugowania, dlatego też na twoim miejscu zastanowił bym się nad 1 z tych:
std:cerr ( https://en.cppreference.com/w/cpp/io/cerr ) aby printować komunikaty na strumień błędówstd::clog ( https://en.cppreference.com/w/cpp/io/clog ) coś ala to wyżejLTTng ( https://lttng.org/ ) mocno rozbudowane narzędzie do tracowania, z możliwością zdalnego odczytywania eventów
Nie powiem ci jak one współpracują z VS, ale zgaduję że strumień błędu raczej będzie w tym IDE wyświetlany :)
Po namyśle: powinno dać się to zrobić przez interfejs pythonowy w GDB. Tzn. gdb (wykorzystując pythona) powiedzmy otwiera named pipe'a, program pisze do niego, gdb(czy raczej ten python odpalony przez gdb) asynchronicznie go czyta i wypisuje jak coś tam jest. Ale a. nie testowałem b. raczej musiałbyś sam to sobie napisać.
Sorry za posta pod postem...
Zakodziłem na szybko prototyp w pythonie+C, działa. Jest quick&dirty i raczej nie zadziała z gdbserverem (nie wiem jak wiżual odpala gdb)... no ale jest pewna baza do dalszych zabaw. Wrzucę link w tym tygodniu.
Prototyp w wersji mocno brzydkiej póki co: https://gitlab.com/alagner/gdbprint (source inferior.py w gdb musisz zawołać). Ważne, żeby aplikacja utworzyła sobie pipe'a najpierw).
Dla potomności: https://sourceware.org/pipermail/gdb/2020-September/048914.html
Przy czym ma to takie ograniczenie, że de facto "wchodzisz" w breakpoint, czytasz stringa i idziesz dalej. Jak masz jakieś timingowy problem to raczej nie będzie dobre, przy systemach wbudowanych gdzie masz ograniczoną liczbę pułapek też może być to niekoniecznie sensowne (no ale Cortexy np. mają semihosting)
Szanuje, można to przepiać na osobny temat w ogóle, bo myślę, że dla wielu osób korzystających z VS może to być przydatna funkcjonalność :-).