опросник

>Suppose you debug a Linux application and put a break-point into a function defined by a dynamically-linked library used by the application. Will that break-point stop any other application that makes use of the same library? If not, please explain why.

Нет, не остановит, потому что copy-on-write.

Auriga?

1. Почитай как реализуются hardware и software breakpoints.

2. Как уже сказали copy-on-write.

3. Хороший ответ есть в ARM Manual насколько я помню. Обдумай какие из адресов постоянны а какие меняются и когда. Вопрос кстати хороший.

4. Такой стэк насколько я помню есть. На счет pro и contra: в основном переключения юзерспейс и кернелспейс, валидация и т.п..

И да. Если это таки Auriga, ее работники на ЛОРе есть, так что палишся.

Да, но не по этой причине.

Не остановит потому что библиотека проецируется на адресное пространство каждого процесса. Разные процессы не могут обращаться к памяти друг друга без специальных механизмов.

Если software breakpoint, то без упоминания copy-on-write ответ как минимум неполон.
Или вы думаете, что если запустить 1000 процессов зависящих от libc то будет использовано памяти 1000*sizeof(libc)?

Кстати, тоже подумал об Ауриге :)

Нет не будет. Но copy-on-write - это следствие фундаментальных проблем (изоляция процессов), без которых ответ как минимум не полон.

московское кадровое агенство, которое не говорит о компании.

Никаких фундаментальных проблем в изоляции процессов без copy-on-write нет. Но память будет жраться.

Хотя, если вдуматься, с формальной стороны вопроса, Вы правы.
Просто вы отвечаете на вопрос «почему оно так», а я скорее «как работает».

Ну консилиум уже выяснил компанию, как видите.
Я бы даже предположил, что Auriga Москва.
Они особо любят вопросы про MMU и процессоры.

По крайней мере вопросы очень характерные для них :)

Насколько я знаю, оно не брякается во всех процессах и при hardware breakpoints. Хотя возможно там уже учитывается адресное пространство конкретного процесса. А что на счёт ядра? Там copy-on-write насколько я знаю нет.

Боюсь соврать, но насколько я помню, hardware breakpoint на x86 работает через соответствующие регистры. И соответственно при смене процесса они сохраняются, и выставляются соответствующие новому процессу.

А copy-on-write в ядре вагон и маленькая тележка насколько я знаю. Но только к теме breakpoint это отношения уже не имеет.

Ну ядро-то не принадлежит какому-то процессу, соответственно брякается во всех.

hardware breakpoint на x86 работает через соответствующие регистры.

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

>Ну ядро-то не принадлежит какому-то процессу, соответственно брякается во всех.

Насчет «соответственно» не понял. Ядро вообще не особо брякается от брекпоинтов в процессе.

>Насчет «соответственно» не понял.

Ядро может выполняться в контексте процесса, я это имел ввиду.

>ВОПРОС 3.

На новых физический кэш (между MMU и внешней памятью), на старых логический (между CPU и MMU).

1. Do not know.
2. Do not know.
3. Do not know.
4. Do not know.

The php monkey coder is me. Work for food. Dwell in basement.

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

Хорошие вопросы! Что за контора? Давайте откроем филиал в Риге :)

По поводу 4 скажите им пусть посмотрят проект L4Linux и не страдают херней.