Для релизной сборки Far 2.0 не генерируется .PDB с символьной информацией
(при сборке в VC). К письму прикреплён патч, который это исправляет. Во
время компиляции отладочная информация складывается в .obj:
Негативные эффекты /debug подавляются, так как в опциях линковщика уже
указаны /incremental:no /OPT:REF /OPT:ICF. Код получается точно такой же с
точностью до меток, но отлаживать его гораздо приятнее.
From: Alexey Pakhunov [mailto:alexe...@gmail.com] Sent: Wednesday, January 07, 2009 11:01 PM
To: fardev@googlegroups.com
Subject: Символы для релизного билда Far 2.0.
День добрый,
Для релизной сборки Far 2.0 не генерируется .PDB с символьной информацией
(при сборке в VC). К письму прикреплён патч, который это исправляет. Во
время компиляции отладочная информация складывается в .obj:
Негативные эффекты /debug подавляются, так как в опциях линковщика уже
указаны /incremental:no /OPT:REF /OPT:ICF. Код получается точно такой же с
точностью до меток, но отлаживать его гораздо приятнее.
> А чем тебе плохо дебаг сборку дебагить я не понимаю?
Ни чем не плохо. Мне удобно отлаживать обе. Если падает релизная сборка в
процессе ежедневной работы, то при наличии символов проще разбираться что
упало и почему. Кроме того, наличие символов никак не влияет на оптимизацию
кода.
>> А чем тебе плохо дебаг сборку дебагить я не понимаю?
AP> Ни чем не плохо. Мне удобно отлаживать обе. Если падает релизная сборка в AP> процессе ежедневной работы, то при наличии символов проще разбираться что Для "что" достаточно мапа.
AP> упало и почему. Кроме того, наличие символов никак не влияет на оптимизацию AP> кода. Влияет (как минимум на время). И на компоновку тоже. Другими словами если такое и делать, то только опционально (по каким-то флагам/параметрам make) но не принудительно.
И - к слову - Zi и Z7 не вполне что бы синонимы - какая цель замены в debug?
> Ни чем не плохо. Мне удобно отлаживать обе. Если падает релизная сборка в > процессе ежедневной работы, то при наличии символов проще разбираться что > упало и почему. Кроме того, наличие символов никак не влияет на оптимизацию > кода.
Так можно сказать, что и по ассемблерному коду все видно. С символами
отладчик покажет и стек и конкретное место. По моему это достаточно
очевидно.
> Влияет (как минимум на время). И на компоновку тоже.
На время сборки? Да. На генерируемый код - нет.
> Другими словами если такое и делать, то только опционально (по каким-то
> флагам/параметрам make) но не принудительно.
Если я скачаю одну из ночных сборок, она у меня упадет, я сделаю дамп в
отладчике и пошлю его в fardev@googlegroups.com вместе в баг репортом,
разработчики Far не смогут посмотреть что же такого я им послал (кроме как
определить адрес креша по map файлу). А при наличии символов это вожможно.
> И - к слову - Zi и Z7 не вполне что бы синонимы - какая цель замены в
debug?
В принципе, можно достичь того же эффекта и с Zi для обоих конфигураций.
Просто Z7 бывает удобнее, если используется precompiled header, вот я его и
влепил по привычке.
-----Original Message-----
From: fardev@googlegroups.com [mailto:fardev@googlegroups.com] On Behalf Of
Iouri Kharon
Sent: Wednesday, January 07, 2009 11:46 PM
To: Alexey Pakhunov
Subject: Re: Символы для релизного билда Far 2.0.
Hi Alexey!
четверг, 8 января 2009 г., Вы писали:
>> А чем тебе плохо дебаг сборку дебагить я не понимаю?
AP> Ни чем не плохо. Мне удобно отлаживать обе. Если падает релизная сборка
в
AP> процессе ежедневной работы, то при наличии символов проще разбираться
что
Для "что" достаточно мапа.
AP> упало и почему. Кроме того, наличие символов никак не влияет на
оптимизацию
AP> кода.
Влияет (как минимум на время). И на компоновку тоже.
Другими словами если такое и делать, то только опционально (по каким-то
флагам/параметрам make) но не принудительно.
И - к слову - Zi и Z7 не вполне что бы синонимы - какая цель замены в debug?
> Ну для себя вообще можешь собирать как угодно, мы разрешаем :)
Не вижу причин для веселья. Релизные символы нужны не мне, они у меня и так
есть. Они нужны вам, разработчикам Far'a, для облегчения вашей жизни. Читай
- для разбора падений и присланных крешдампов.
-----Original Message-----
From: fardev@googlegroups.com [mailto:fardev@googlegroups.com] On Behalf Of
Alex Yaroslavsky
Sent: Wednesday, January 07, 2009 11:51 PM
To: fardev@googlegroups.com
Subject: Re: Символы для релизного билда Far 2.0.
Ну для себя вообще можешь собирать как угодно, мы разрешаем :)
> Ни чем не плохо. Мне удобно отлаживать обе. Если падает релизная сборка в
> процессе ежедневной работы, то при наличии символов проще разбираться что
> упало и почему. Кроме того, наличие символов никак не влияет на
оптимизацию
> кода.
> > Ну для себя вообще можешь собирать как угодно, мы разрешаем :)
> Не вижу причин для веселья. Релизные символы нужны не мне, они у меня и так > есть. Они нужны вам, разработчикам Far'a, для облегчения вашей жизни. Читай > - для разбора падений и присланных крешдампов.
> Best regards, > Alex.
> -----Original Message----- > From: fardev@googlegroups.com [mailto:fardev@googlegroups.com] On Behalf > Of > Alex Yaroslavsky > Sent: Wednesday, January 07, 2009 11:51 PM > To: fardev@googlegroups.com > Subject: Re: Символы для релизного билда Far 2.0.
> Ну для себя вообще можешь собирать как угодно, мы разрешаем :)
> > Ни чем не плохо. Мне удобно отлаживать обе. Если падает релизная сборка в > > процессе ежедневной работы, то при наличии символов проще разбираться что > > упало и почему. Кроме того, наличие символов никак не влияет на > оптимизацию > > кода.
AP> Так можно сказать, что и по ассемблерному коду все видно. С символами AP> отладчик покажет и стек и конкретное место. По моему это достаточно Место - покажет. Стек - не всегда (более того "не всегда _правильно_")
>> Влияет (как минимум на время). И на компоновку тоже.
AP> На время сборки? Да. На генерируемый код - нет. Бывает что и на код. А на бинарник (я не случайно помянул компоновку) почти всегда
>> Другими словами если такое и делать, то только опционально (по каким-то >> флагам/параметрам make) но не принудительно.
AP> Если я скачаю одну из ночных сборок, она у меня упадет, я сделаю дамп в "отладка" и "скачаю ночную сборку" малость ортогональны :). Первое имеет смысл только со стороны программиста, второе предназначено для юзверей.
AP> отладчике и пошлю его в fardev@googlegroups.com вместе в баг репортом, Лучше не надо - от таких "посылок" только время (как правило) теряется. Если возможно описать последовательность действий приводящий к неправильному результату (в частности падению) это куда полезней.
AP> разработчики Far не смогут посмотреть что же такого я им послал (кроме как AP> определить адрес креша по map файлу). А при наличии символов это вожможно. Если ты предпочитаешь работать с дампами это ещё не повод считать, что и все так работают. Вот тебе простой пример - в тех редких случаях когда мне что-то в фаре надо посмотреть в отладчике используется tds а не pdb.
Если хочется чем-то помочь есть ровно две возможности - сделать(/исправить) самому или делать так как "принято" в данной конкретной разработке. А "бесплатные советы"... :)
> Место - покажет. Стек - не всегда (более того "не всегда _правильно_")
Ну map файл стек вообще никогда не показывает.
> Бывает что и на код. А на бинарник (я не случайно помянул компоновку) почти > всегда
Это влияние ограничивается метками, порядком упаковки функций. Достаточно посмотреть на разницу в ассемблерных листингах с /Zi или /Z7 и без этой опции. Некоторые метки переименованы. Некоторые функции перемещены относительно друг от друга. На поведение кода это никак не влияет,
> "отладка" и "скачаю ночную сборку" малость ортогональны :). Первое имеет > смысл только со стороны программиста, второе предназначено для юзверей.
Юзвери тоже не идиоты. Многие из них вполне способны снять дамп и прислать его. В большинстве случаев это те же программисты, которым сидеть и отлаживать far или плагин не досуг. А прислать дамп - пожалуйста.
> Лучше не надо - от таких "посылок" только время (как правило) теряется.
Гм. Мой опыт говорит об обратном. Но это дейстительно зависит от стиля работы принятого в команде. Не буду настаивать.
> Если возможно > описать последовательность действий приводящий к неправильному результату (в > частности падению) это куда полезней.
А если такой возможности нет? Просто случился случайный креш. Или скажем на моей системе установлен какой-то софт, который косвенно повлиял на падения фара, а на машине разработчика этого софта нет? Будет вечный not repro, а баг так и не будет исправлен.
Я кстати могу прислать такой
> Если ты предпочитаешь работать с дампами это ещё не повод считать, что и все так > работают.
Я так и не считаю. С моеё стороны ситуация проста как день. Включив генерацию символов в релизном билде можно получить "кое что за даром" - возможность отладки релизной версии. Возможность не отладивать релизную версию при этом никуда не девается. Качество генерируемого бинарника тоже не страдает ни капли. Суммарная "стоимость" этого изменения - немного меньше свободного места на диске и чуть менее шустрый билд. При том, что ни первое ни второне никак не критично, в случае Far'а. Не вижу причин почему бы воспользоваться этой возможностью.
> Если хочется чем-то помочь есть ровно две возможности - сделать(/исправить) самому > или делать так как "принято" в данной конкретной разработке. А "бесплатные > советы"... :)
Я думаю что это и так понятно, но на всякий случай скажу. Небо не упадет на землю, если мой патч не найдет понимания в сердцах fardev. Даже если вообразить, что вы 100% неправы, а я на коне и весь в белом. Вы считаете, что это исправление не нужно? Я удивлюсь, попробую объяснить преимущества и понять аргуметны оппонента. Если не получится - ничего страшного.
Должно было быть: "Я кстати могу прислать такой дамп. Far падает просто при запуске из-за того что не может открыть хендл консоли. Хендл не открывается из-за постороннего софта. Но так как Far не проверяет результат CreateFile(L"CONOUT$"), то само падение происходит сильно познее. Разобраться что именно происходит без дампа под рукой наверное можно будет, но с дампом как про проще".
AP> Гм. Мой опыт говорит об обратном. Но это дейстительно зависит от стиля AP> работы принятого в команде. Не буду настаивать. ваш опыт говорит, что юзера ctrl-break на клавах не жмут, наш, что дампы никому нафиг не сдались. такие дела.
Ну и это, раз ты тут к нам забрёл, вопрос, по твоему блогу
>остается отсутствие человеческой поддержки удаленного доступа к консоли (telnet/SSH)
На это есть какие то планы? И может поломать обратно поддержку иврита чтоб хоть как в win9x работала? А то видно что пытались сделать "полную" обломались и бросили поломав окончательно.
>>> Ну map файл стек вообще никогда не показывает. >> С fexcept, показывает.
> А регистры и локальные переменные? Содержимое памяти? :-)
К твоему удивлению, даже это показывает минус локальные переменые. Попробуй один раз. Уже сколько лет тока с "дампами" fexcept работаем и всё ок. И самое удобное что со стороны пользователя оно практически прозрачно.
Без понятия. В Win7 довольно сильно переделали внутренности консоли, но внешне это не должно быть заметно. Для приложений все должно работать как и раньше.
> И может поломать обратно поддержку иврита чтоб хоть как в win9x работала? > А то видно что пытались сделать "полную" обломались и бросили поломав окончательно.
Right to left не работает? А можно поподробнее? Может ссылка на описание проблем есть?
> Без понятия. В Win7 довольно сильно переделали внутренности консоли, > но внешне это не должно быть заметно. Для приложений все должно > работать как и раньше.
>> И может поломать обратно поддержку иврита чтоб хоть как в win9x работала? >> А то видно что пытались сделать "полную" обломались и бросили поломав окончательно.
> Right to left не работает? А можно поподробнее? Может ссылка на > описание проблем есть?
Да нет, проблема как раз в том что right to left "пытается работать". В win9x rtl небыло но хоть буквы выводились и можно было наоборот читать. А начиная с NT вопервых офф. заявили что rtl языки в консоли не поддерживаются (хотя со времён доса отлично работали), во вторых в Люциде Консоль их нет, а в третих если "обойти" первое и второе то являются очень забавные глюки при отрисовке консоли так как ваш рисовалщик как мне кажется пытается делать rtl - самые забавные глюки это когда например есть текст на иврите и мы перерисовываем только часть буффера консоли. Можно очень классно видеть в фаре имея файлы с ивритом в имени и двигаясь по ним курсором (всё это после того как вообще добились показа ивритских символов в консоли конечно) или открыть иврит в редакторе и двигать курсор и делать пометку. Эфекты получаются отменные. Ну а вообще для начала неплохо бы было если бы MS выпустили нормальный и полный моноширный TrueType шрифт для консоли а то люцида хилая очень. Может ты там можешь намекнуть кому то что есть ещё люди которые консоль используют.
Может ли он пробежаться по стеку и показать содержимое nonvolatile регистров не на вершине стека? Про локальные переменные и глобальную память я уже говорил. Про анализ кучи и прочие предести я даже не заикаюсь.
И где взять x64 версию ExcDump.dll и HaronDemangle.dll? Исходников последнего я не вижу.
> Уже сколько лет тока с "дампами" fexcept работаем и всё ок.
Как будто я предлагаю перестать пользоваться fexcept. Пользуйтесь на здоровье. Плюс появится возможность пользоваться и отладчиком тоже.
> И самое удобное что со стороны пользователя оно практически прозрачно.
Кстати fexcept можно подкрутить, чтобы он создавал и дамп, который будет понятен Windbg. Но я знаю, знаю - сделай сам.
> Да нет, проблема как раз в том что right to left "пытается работать". > В win9x rtl небыло но хоть буквы выводились и можно было наоборот > читать. > ....
Хм. Интересно. Я спрашу текущего владельца на счет их планов.
> А начиная с NT вопервых офф. заявили что rtl языки в консоли не > поддерживаются (хотя со времён доса отлично работали)
Я сильно подозреваю, впрочем, что это и будет ответом. Посмотрим.
> А можно поподробнее про переделки? Особенно, какие плюшки из них можно > извлечь.
Я не знаю подробностей. Значительный часть консольного кода вынесли из CSRSS и для консольных приложений теперь запускается отдельный хост (conhost.exe). Какие там были изменения в функциональности - без понятия.
