Два последовательных ярлыка образуют два разных базовых блока или они одинаковы в сборке

Question

Я застрял на проблеме с основными блоками

Если у нас есть сборка как таковая

lea random, eax
label1
label2
mov $5, ebx

- это базовые блоки, организованные так:

lea random, eax
-----------------
label1:
label2:
mov $5, ebx

или как это:

lea random, eax
----------------
label1:
----------------
label2:
mov $5, ebx

Потому что, как я понимаю, базовый блок - это блок кода, который выполняется без разрывов, поэтому не имеет метки или перехода в середине, только возможно на концах, но если у нас есть 2 последовательных метки, они технически не указывают на один и тот же адрес и, следовательно, не являются разными «операциями» и попадают в один и тот же блок?

Спасибо!

Answer 1

Любая метка, являющаяся целью ветвления , может считаться началом базового блока.

В действительности не имеет значения, смотрите ли вы на то, что он падает через пустой базовый блок, прежде чем перейти к «реальному», или же вы решаете, что обе метки находятся в одном и том же базовом блоке. Делай, что удобно. Обе интерпретации совершенно верны.

Но IMO последнее более логично: пустой базовый блок на самом деле не существует. Если вы пишете компилятор, пустой BB - это оптимизация / упрощение, ожидающее вашего контроля. График потока. Но не тот, который необходим для правильности. Но если обратный инжиниринг из asm обратно в граф потока управления, добавление дополнительного пустого узла является ненужной сложностью.

---

Если метка не является целью ветвления, она не запускает базовый блок.

Вы можете размещать метки где угодно (включая данные), но если вы на самом деле никуда не переходите, это не BB. Вы можете просто взять его адрес для какой-то цели, помимо (в конечном итоге), прыжка туда, например, в качестве якоря для вычисления других местоположений относительно него.

Если вы думаете, что у вас есть 2 ББ подряд, но на самом деле вы никогда не переходите к метке в начале 2-го, то фактически у вас есть 1 ББ большего размера. Это обобщение идеи о том, что не нужно вносить дополнительную сложность в ваш CFG при переходе от asm к логике программы.