Здравствуйте, c-smile, Вы писали:
CS>А кстати почему?
по объему, ооочень много кода придется писать. откладывали, не до этого было. сейчас, mingw-w64 очень хорошо поддерживает WINAPI, вот и время появилось для написания своего с-рантайма.
к концу года, планируем, хотя бы в бету выйти.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Ну, если рантайм с дефектами считать "хорошей фичей языка", то да.
S>Насколько я понимаю, сказано о MinGW.
S>Но в "дистрибутиве" MinGW присутствует не только original (old) Visual C runtime, MSVCRT S>а также C runtime-ы студий, от 6-ой, до 10-й.
S>Тогда не понятна фраза, упомянутая выше.
насколько я помню ту тему, там как раз таки говорилось о том, что микрософтовский рантайм с багами.
и таки да, MinGW пока не имеет собственного рантайма.
сейчас пилим с коллегами в рамках mingw-w64 собственный рантайм ,который будет лишен микрософтовских извечных багов, получит расширение в плане POSIX насколько это возможно в вендуз, и возможность статической линковки. (ведь от msvcrt.dll невозможно отцепиться в принципе(легально))
S>Выбор VS, не дает что-либо сверх, того что можно получить, выбрав MinGW.
только минусы.
S>Может существуют в природе, реализации С runtime, на платформе windows, не microsoft ?
нет.
S>P.S. glibc же нет под MinGW, я правильно понимаю ? или есть ?
glibc это не то что ты подумал. реализация С-рантайма в линукс зовется libc.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, jazzer, Вы писали:
J>>Если я правильно помню, КОМовские интерфейсы пишутся на IDL, а дальше уже есть трансляторы IDL в любой (почти) язык. J>>Так что компилятор таки ни при чем. A>реализацию-то этих интерфейсов надо как-то писать
Это проблема? Есть ATL, в конце концов. Не помню, чтоб ей требовалась какая-то специальная поддержка компилятора.
A>>>>>а у вас в никсах как? J>>А отлаживать — отладчиком, вестимо. GDB к твоим услугам. strip автоматом вставит в foo ссылку на foo.debug, так что просто gdb foo foo.core — и он сам все найдет. A>а в винде с mingw как?
Понятия не имею, мне винда параллельна, я в никсе живу. Ты ж про никсы спрашивал
Я не знаю, в каком виде генерит отладочные символы GCC под виндой. Если в том виде, в котором их понимает WinDbg — тогда проблем нет, вроде как.
Это, скорее, вопрос к WinDbg — какие форматы debug info он умеет понимать.
Но!
Вот тут интернеты говорят, что у GCC есть флажок -gcoff (вместо обычного -g), который сгенерит debug info в формате coff, который понимает WinDbg.
Еше есть winedbg (из проекта Wine — эмуляция винды под линуксом) — он умеет понимать виндовые минидампы.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
S>>>>Может существуют в природе, реализации С runtime, на платформе windows, не microsoft ?
X>>>нет.
CS>>А кстати почему?
A>да наверняка есть, у bcc или dmc. A>открытых только нету
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, jazzer, Вы писали:
A>>>а у вас в никсах как? J>>
J>>strip foo -f foo.debug
J>>
J>>debug info из foo переехала в foo.debug, foo теперь без debug info, его можно отправлять клиенту.
А>Это где (или давно ли) так? Посмотрел на наших линуховых машинах — нет ключа -f у strip.
Установи elfutils поновее. А>Есть какая-то новая фича, чтоб именно как pdb-файлы? Чтоб вынести только отладочную инфу (а не иметь strip'нутый и нестрипнутый модуль) и подцеплять её потом в GDB?
Да нет, не новая. Это новая фича strip, скорее, потому что все то же самое можно сделать вручную в несколько шагов:
--only-keep-debug
Strip a file, removing contents of any sections that would not be stripped by --strip-debug and leaving the
debugging sections intact. In ELF files, this preserves all note sections in the output.
The intention is that this option will be used in conjunction with --add-gnu-debuglink to create a two part
executable. One a stripped binary which will occupy less space in RAM and in a distribution and the second a
debugging information file which is only needed if debugging abilities are required. The suggested procedure
to create these files is as follows:
1.<Link the executable as normal. Assuming that is is called>
"foo" then...
1.<Run "objcopy --only-keep-debug foo foo.dbg" to>
create a file containing the debugging info.
1.<Run "objcopy --strip-debug foo" to create a>
stripped executable.
1.<Run "objcopy --add-gnu-debuglink=foo.dbg foo">
to add a link to the debugging info into the stripped executable.
Note---the choice of ".dbg" as an extension for the debug info file is arbitrary. Also the
"--only-keep-debug" step is optional. You could instead do this:
1.<Link the executable as normal.>
1.<Copy "foo" to "foo.full">
1.<Run "objcopy --strip-debug foo">
1.<Run "objcopy --add-gnu-debuglink=foo.full foo">
i.e., the file pointed to by the --add-gnu-debuglink can be the full executable. It does not have to be a
file created by the --only-keep-debug switch.
Note---this switch is only intended for use on fully linked files. It does not make sense to use it on
object files where the debugging information may be incomplete. Besides the gnu_debuglink feature currently
only supports the presence of one filename containing debugging information, not multiple filenames on a one-
per-object-file basis.
Здравствуйте, c-smile, Вы писали:
CS>Да вроде как в с runtime в visual studio помнится был открыт: CS>http://msdn.microsoft.com/en-us/library/aa296413(v=vs.60).aspx CS>или это не то?
это "то", но:
1. по обсуждению в переписке помню, говорилось об лицензионных ограничениях на сорцы, которые, делают невозможным использование этих сорцов как базы для MinGW C-runtime.
2. лицензия ограничивала статическую линковку с msvcrt так, что только микрософткомпилятору позволено это делать. всем остальным позволено использовать динамическую версию.
2.1. в случае, если исходники микрософт C-runtime собираются как динамическая версия — то имя dll`ки должно начинаться с префикса msvcrt*
мы решили брать код из проекта wine. и тесты в том числе.
pthreads библиотека уже реализована разрабами mingw-w64(winpthreads), и она так же войдет в MinGW C-runtime. и еще некоторые функции из стандарта POSIX.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
S>>Выбор VS, не дает что-либо сверх, того что можно получить, выбрав MinGW. X>только минусы.
да конечно, куча расширений языка, в т.ч. для взаимодействия с другими языками, ИДЕ, это все минусы.
как там кстати, MinGW уже научилась генерить .pdb файлы? или там есть что-то свое для postmortem отладки?
Ну, если рантайм с дефектами считать "хорошей фичей языка", то да.
Насколько я понимаю, сказано о MinGW.
Но в "дистрибутиве" MinGW присутствует не только original (old) Visual C runtime, MSVCRT
а также C runtime-ы студий, от 6-ой, до 10-й.
Тогда не понятна фраза, упомянутая выше.
Вася ведь использует все тоже самое (что касается рантаймов С).
Выбор VS, не дает что-либо сверх, того что можно получить, выбрав MinGW.
Или я не так понял, и все с точностью до наоборот.
Может существуют в природе, реализации С runtime, на платформе windows, не microsoft ?
P.S. glibc же нет под MinGW, я правильно понимаю ? или есть ?
или может есть какой другой рантайм ?
--
С уваженим, Сергей
Только на РСДН помимо ответа на вопрос, можно получить еще список орфографических ошибок и узнать что-то новое из грамматики английского языка (c) http://www.rsdn.ru/forum/cpp/4720035.1.aspx
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, niXman, Вы писали:
S>>>Выбор VS, не дает что-либо сверх, того что можно получить, выбрав MinGW. X>>только минусы.
A>куча расширений языка
куча нарушений стандарта.
A>для взаимодействия с другими языками, ИДЕ
зачем оно? оО
A>как там кстати, MinGW уже научилась генерить .pdb файлы? или там есть что-то свое для postmortem отладки?
объясни, что это такое?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, c-smile, Вы писали:
S>>>Может существуют в природе, реализации С runtime, на платформе windows, не microsoft ?
X>>нет.
CS>А кстати почему?
да наверняка есть, у bcc или dmc.
открытых только нету
Здравствуйте, niXman, Вы писали:
S>>>>Выбор VS, не дает что-либо сверх, того что можно получить, выбрав MinGW. X>>>только минусы.
A>>куча расширений языка X>куча нарушений стандарта.
расширения языка это не нарушения стандарта, если ты о них
к тому же нарушения стандарта и в гцц есть, ну и что?
A>>для взаимодействия с другими языками, ИДЕ X>зачем оно? оО
что — оно?
ИДЕ зачем? даже хз как объяснить. с кодом работать, ALM всякое там
а взаимодействие с другими языками нужно тогда когда в ОС развито много разных языков, а не один только Си.
COM там всякий для скриптов, CLI для .NET, __asm для асма, соглашения вызова функций
A>>как там кстати, MinGW уже научилась генерить .pdb файлы? или там есть что-то свое для postmortem отладки? X>объясни, что это такое?
что именно? pdb или postmortem отладка?
pdb — это файлы чтобы хранить и распространять отладочную информацию
postmortem отладка — это отладка минидампов (aka крешдампов)
упаковываешь программу какойнить themida, даешь юзеру, прога у юзера падает, он тебе отправляет крешдамп, открываешь его в отладчике и отлаживаешь.
а у вас в никсах как?
Здравствуйте, Abyx, Вы писали:
A>>>куча расширений языка X>>куча нарушений стандарта. A>расширения языка это не нарушения стандарта, если ты о них A>к тому же нарушения стандарта и в гцц есть, ну и что?
Ну, не сравнить с художествами VS.
A>а взаимодействие с другими языками нужно тогда когда в ОС развито много разных языков, а не один только Си. A>COM там всякий для скриптов, CLI для .NET, __asm для асма, соглашения вызова функций
Какое отношение все это имеет к компилятору? COM вроде — это чистый Си, не? .NET в С++-компиляторе нафиг не уперся, асм в GCC всегда был.
A>упаковываешь программу какойнить themida, даешь юзеру, прога у юзера падает, он тебе отправляет крешдамп, открываешь его в отладчике и отлаживаешь. A>а у вас в никсах как?
strip foo -f foo.debug
debug info из foo переехала в foo.debug, foo теперь без debug info, его можно отправлять клиенту.
Здравствуйте, Abyx, Вы писали:
A>расширения языка это не нарушения стандарта, если ты о них
зачем они, если они не переносимы и не стандартизованы?
A>к тому же нарушения стандарта и в гцц есть, ну и что?
если ты говоришь о расширениях — да, есть. но они не нужны в 99% случаев.
если же ты говоришь про реальные нарушения стандарта — их в разы меньше, чем в масдайке.
A>pdb — это файлы чтобы хранить и распространять отладочную информацию
gcc умеет. в мингве не проверял.
A>postmortem отладка — это отладка минидампов (aka крешдампов)
смотри выше.
A>упаковываешь программу какойнить themida, даешь юзеру, прога у юзера падает, он тебе отправляет крешдамп, открываешь его в отладчике и отлаживаешь. A>а у вас в никсах как?
так же.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>зачем они, если они не переносимы и не стандартизованы?
единственное, что я когда-либо юзал из расширений GCC — typeof(). да и то, пока не появился decltype()
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, jazzer, Вы писали:
A>>а взаимодействие с другими языками нужно тогда когда в ОС развито много разных языков, а не один только Си. A>>COM там всякий для скриптов, CLI для .NET, __asm для асма, соглашения вызова функций
J>Какое отношение все это имеет к компилятору? COM вроде — это чистый Си, не? .NET в С++-компиляторе нафиг не уперся, асм в GCC всегда был.
нет, COM на чистом Си это куча страшных макросов и прочей мерзости.
сам понимаешь, руками таблицу виртуальных методов собирать — это несколько неудобно.
а в стандарте С++ внезапно нет никаких *таблиц* методов. вот и вылазят расширения языка.
.NET в С++ компиляторе нужен чтобы делать нормальные мосты с .NET кодом, типа UI/скрипты на дотнете, а логику на С++
asm("") несколько неюзабелен, по сравнению с __asm и __asm {}
A>>упаковываешь программу какойнить themida, даешь юзеру, прога у юзера падает, он тебе отправляет крешдамп, открываешь его в отладчике и отлаживаешь. A>>а у вас в никсах как? J>
J>strip foo -f foo.debug
J>
J>debug info из foo переехала в foo.debug, foo теперь без debug info, его можно отправлять клиенту.
это гуд.
а чем делать крешдамп и чем его отлаживать?
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, niXman, Вы писали:
X>>зачем они, если они не переносимы и не стандартизованы? X>единственное, что я когда-либо юзал из расширений GCC — typeof(). да и то, пока не появился decltype()
если программы не писать — даже typeof юзать не придется
Здравствуйте, niXman, Вы писали:
A>>pdb — это файлы чтобы хранить и распространять отладочную информацию X>gcc умеет. в мингве не проверял.
что умеет? pdb это конкретный формат файла.
A>>postmortem отладка — это отладка минидампов (aka крешдампов) X>смотри выше.
смотри ответ там же
A>>упаковываешь программу какойнить themida, даешь юзеру, прога у юзера падает, он тебе отправляет крешдамп, открываешь его в отладчике и отлаживаешь. A>>а у вас в никсах как? X>так же.
пока не заметил.
Здравствуйте, niXman, Вы писали:
A>>а чем делать крешдамп и чем его отлаживать? X>крешдампы создает ядро. используются gdb, как обычно.
тема про винду, если ты вдруг забыл
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Abyx, Вы писали:
A>>pdb это конкретный формат файла. X>зачем gcc масдайный pdb? X>у него есть свой аналог.
ок.
мы начали с того, что "MSVS не нужна потому что есть mingw".
типа под виндой можно снести MSVS и юзать mingw, только рантайм в длл, ну и хрен с ним.
только вот мне пока непонятно, как с mingw делать крешдампы.
у MS есть ссылка на pdb в PE заголовке, сервера с .pdb файлами библиотек MS, dbghelp.dll которая делает дампы, отладчики которые дебажат дампы и умеют находить символы.
Здравствуйте, Abyx, Вы писали:
J>>Какое отношение все это имеет к компилятору? COM вроде — это чистый Си, не? .NET в С++-компиляторе нафиг не уперся, асм в GCC всегда был. A>нет, COM на чистом Си это куча страшных макросов и прочей мерзости. A>сам понимаешь, руками таблицу виртуальных методов собирать — это несколько неудобно. A>а в стандарте С++ внезапно нет никаких *таблиц* методов. вот и вылазят расширения языка.
Если я правильно помню, КОМовские интерфейсы пишутся на IDL, а дальше уже есть трансляторы IDL в любой (почти) язык.
Так что компилятор таки ни при чем.
A>.NET в С++ компиляторе нужен чтобы делать нормальные мосты с .NET кодом, типа UI/скрипты на дотнете, а логику на С++
ХЗ, эта проблематика далека от меня.
У нас есть гуй на шарпе, но сишный сервер с ним общается по сети.
A>asm("") несколько неюзабелен, по сравнению с __asm и __asm {}
почему? Что с ним не так?
Ну и есть компиляторные билтины, которые фактически представляют собой асм, только с интерфейсом сишных функций.
A>>>а у вас в никсах как? J>>
J>>strip foo -f foo.debug
J>>
J>>debug info из foo переехала в foo.debug, foo теперь без debug info, его можно отправлять клиенту. A>это гуд. A>а чем делать крешдамп и чем его отлаживать?
крешдамп (в никсах он называется core) делается самой системой (но есть способы его сгенерить и из самой программы, в том числе и не роняющие ее).
А отлаживать — отладчиком, вестимо. GDB к твоим услугам. strip автоматом вставит в foo ссылку на foo.debug, так что просто gdb foo foo.core — и он сам все найдет.
Здравствуйте, jazzer, Вы писали:
J>Если я правильно помню, КОМовские интерфейсы пишутся на IDL, а дальше уже есть трансляторы IDL в любой (почти) язык. J>Так что компилятор таки ни при чем.
реализацию-то этих интерфейсов надо как-то писать
A>>>>а у вас в никсах как? J>>>
J>>>strip foo -f foo.debug
J>>>
J>>>debug info из foo переехала в foo.debug, foo теперь без debug info, его можно отправлять клиенту. A>>это гуд. A>>а чем делать крешдамп и чем его отлаживать? J>крешдамп (в никсах он называется core) делается самой системой (но есть способы его сгенерить и из самой программы, в том числе и не роняющие ее). J>А отлаживать — отладчиком, вестимо. GDB к твоим услугам. strip автоматом вставит в foo ссылку на foo.debug, так что просто gdb foo foo.core — и он сам все найдет.
а в винде с mingw как?
Здравствуйте, Abyx, Вы писали:
A>а в винде с mingw как?
так же, с тем лишь отличием, как я писал выше, что gdb вряд ли понимает вендовый крэшдамп формат.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
A>>а в винде с mingw как? X>так же, с тем лишь отличием, как я писал выше, что gdb вряд ли понимает вендовый крэшдамп формат.
так чем тогда в винде крешдамп создать, чтоб gdb его понял?
Только на РСДН помимо ответа на вопрос, можно получить еще список орфографических ошибок и узнать что-то новое из грамматики английского языка (c) http://www.rsdn.ru/forum/cpp/4720035.1.aspx
Здравствуйте, jazzer, Вы писали:
A>>а у вас в никсах как? J>
J>strip foo -f foo.debug
J>
J>debug info из foo переехала в foo.debug, foo теперь без debug info, его можно отправлять клиенту.
Это где (или давно ли) так? Посмотрел на наших линуховых машинах — нет ключа -f у strip.
Есть какая-то новая фича, чтоб именно как pdb-файлы? Чтоб вынести только отладочную инфу (а не иметь strip'нутый и нестрипнутый модуль) и подцеплять её потом в GDB?
