как графы строить?

как графы флоу и колл фанкшн строить. особо для self modifying code. как обходить, когда перерисовывать?

дайте примеры почитать, гитхаб или еще чего.

Расскажите пожалуйста философию этого дела. Ключевую идею, суть, основной прием. Очень хочется подумать, повтыкать.

Что бы Инди не запугал всех, и не задавил всех авторитетом, давайте сделаем эту ветку в духе картин импрессионистов, футуристов, кубистов, где Инди будет в роли Шишкина со своим реализмом. Хочется увидеть множество цветов и соцветий. И больше детского юмора и легкости господа присоединяйтесь все! (детского - т.е. без оскорбительных отжигов и мата, да помогут мне в этом модераторы).

 

на скриптах самомодифицированный кодец куда проще... например взять Питон: скрипт считывает себя как текст, парсит себя с помощью модуля ast, обходит абстрактное синтаксическое дерево и делает соответсвующие модификации, сериализует модифицированное дерево в текст и записывает обратно... с дотнетом тоже достаточно удобно это делать, но нужно будет с собой что-то типа Dnlib'а или Mono.Cecil таскать... ну и PE будет залочен системой...

ну а кроме шуток посмотри: https://github.com/topics/self-modifying-code - может найдешь для себя что...

 

а смысл юзать питон? тупо переброс рипа в адрес, куда предварительно кинуть опкод. И это можно как балоном с краской по стене графити.... по хипу набросать байтов. Питон, уж слишком тяжеловесно.
Обходит абстактное синтаксическое дерево - как он его глядя в байты воссоздает?

гит зашел. есть еще?

 

скрипт - текст, какие байты?

 

лол, начинает казаться что асм - программирование для тех кто в асме шарит.
чото типа нет опыта работы - чтобы набрать - идите работать -нам только с опытом
спасибо за пост, нифига не понял!

 

какой сфеерический бред в вакууме. для сериализации есть или появилось pickle

Код (Text):

1.  
2. # c++ style base CTOR invocation (call->call->call...)
3. #
4. class base0:
5.    def __init__(self):
6.       self.base0var = 777
7.       print('base0 ctor')
8. class base1(base0):
9.    def __init__(self):
10.       super().__init__()
11.       print('base1 ctor')
12. class derived(base1):
13.    def __init__(self):
14.       super().__init__()
15.       print('derived ctor')
16. ob = derived()
17. ob.base0var = 666
18. s = open('dump.dat', 'wb')
19. pickle.dump(ob, s)
20. …
21. l = open('dump.dat', 'rb')
22. ob = pickle.load(l) # type and members/methods stored in file
23.  

я не особо манулы курил - не помню нужен там self или нет в вызове super

 

ни парсинг, ни сериализация, ни селф-модифаи(посмотреть в кайф, но есть свой) мне не нужны. Две задачи.
1) эффективная структура данных и функции работы с ней. Использоваться будет дальше для отрисовывки графов control flow и call graph
2) плюс к 1) специфика, когда регулярно переписываются одни и теже страницы памяти, существенно изменяющие графы.

 

ТС, а зачем вам строить графы и флоу? Т.е. каких целей вы хотите достичь и какие задачи решить? (кстати что делает с ними Инде тоже интересно, расскажите?) Планируется ли какая-то визуализация?

 

ormoulu, смотрели фильм мэн ин блэк третью часть? там был персонаж который видел все миры одновременно. В жизни будет что-то по проще, как минута-минута тридцать , да и не зачем такие толстые цветные линии, появление\исчезновение вершин и ребер и игрой цвета, вполне достаточно при визуализации.

 

да любой класс - это и есть структура. лишнего там не будет если сам не напилишь всякой ерунды. другое дело когда класс например на питоне или ином мунспике - это да, надобы и пореверсеть что там к чему. но всё это складывается в поиск по динамической куче ну и разумеется до последующих аллокаций, хотя всё это и так в исходниках написано

 

Чего-то непонятно, вы граф чего строить будете, миров, соседей? Вроде бы кода. А зачем? Что будет на графе? И что дают эти зеленые полоски?

 

да он дело говорит. если съесть 300мкг лсд за раз - то реально все миры увидишь. самая проблема в том что будучи там - нет протокола для передачи информации сюда.

 

чет я не понял мысль. речь ведь не с точки зрения си структур, а про арей-ксор-листы, хэшмапы, деревья. я, наверно, просто не понял вашу мысль.

чувство удовлетворения

 

ну как вы себе представляете сериализацию и что нужно в ней сохранить и что нужно восстановить потом? решать то вам. странно что вы задаётесь таким вопросом. это всегда структура, можете например id(str()) питона поанализировать, в динамической памяти - ога, поменять значение - оо отображается и в интерпретаторе - и поехали.
другое дело - когда аффторы это дело зажимают или криптуют до кучи - но это тоже лечится. правда совсем другими подходами.

 

для хранения графа кода в общем случае подойдут *драматическая пауза* графы... можно наверное обойтись односвязными списками, если код будешь отображать линейно, без попытки разбора всяческих сложных ифов, свичей и джамп-тейблов, но нужно подумать, все ли возможные в твоем случае ситуации эта структура данных покроет...

не понимаю, что имеется ввиду...

 

имеется ввиду динамическое отображение состояния программы, то есть сейчас одно, а через секунду там новый элемент нарисовался например. вопрос, если я правильно понял, - в том чтобы это дело сохранить а затем загрузить. просто не совсем понимаю - а в чём проблема то? если тс подразумевает некие встроенные волшебные функции - то для компилируемого языка такая магия не прокатит

 

Очевидно надо хранить все возможные пары адрес+значение, добавляя новые по ходу исполнения(/трассы), если таки код себя модифицирует. Если какой-то элемент (инструкция по адресу n/функция с точкой входа n) не соответствует в точности одному из своих предыдущих состояний - это новый узел графа. Подводный камешек здесь в том, что о том, что не получало или не могло получить управление в ходе исполнения, таким способом судить нельзя. В отрыве от самой задачи больше ничего нельзя сказать. Ну и далеко не каждый фреймворк потянет рисование графа 300к+ узлов.

 

да любое потянет - вопрос просто в доступной озу и ядрах цпу. это при условии что исполняется не говнокод. как пример - инкрементальное линкование большого проекта.

 

и это тоже, но скорее, то что f13nd сказал, куда сильнее беспокоит. По сохранению не знаю, думал может во времена ceph и zfs есть какие-то чудеса? уронили дамп, а потом как в иммутабельных структурах.

 

я понял, специально говорите на индусском языке, шоп новички и дальше не понимали нечего