Ошибка в вычислениях адресов у GCC ?

Hello Andy.

AG>> Это как себе задачу поставить. AG>> Если только навигировать по ошибкам, то может быть. AG>> Я обычно хочу достичь вывода об ошибках а-ля CL.

AM> Что такое CL?

компилятор VC++

AG>> Писать парсилку на C++ иногда проще, чем составить AG>> регулярное выражение.

AM> паpсеp нyжно писать, потом кyда-то подключать, либо в make его засовывать, AM> как пpомежyточный обpаботчик, либо еще как-то. Делал pаньше также, AM> мyтно, долго, со вpемением накапливается кyча мелких yтилит, в котоpых AM> сложно pазобpаться. AM> regexp же в ноpмальном pедактоpе yказывается в соответствyющей настpойке, AM> потом пpо это забывается.

А как переключать regexp при работе с разными компиллерами ?

Alexey

Hello Harry.

HZ> Hадо почитать доку, в которой описан ключ --no_wrap_diagnostics, HZ> который означает "Don't wrap long lines in diagnostic messages". Все HZ> выдается в одну строку.

Мы ж обсуждаем возможности технологии сликкера. А если в компиллере нет возможности изменить формат вывода? Я ж IAR привел для примера.

Alexey

Thu, 10 Mar 2005 09:52:00 +0300 Alexey Gushin wrote to Harry Zhurov:

HZ>> Hадо почитать доку, в которой описан ключ --no_wrap_diagnostics, HZ>> который означает "Don't wrap long lines in diagnostic messages". Все HZ>> выдается в одну строку.

AG> Мы ж обсуждаем возможности технологии сликкера. AG> А если в компиллере нет возможности изменить формат вывода? AG> Я ж IAR привел для примера.

Если мы обсуждаем возможности слика, то замечу, что у него есть встроенный язык Slick-C, на котором реализована вся функциональность. И на нем в том числе можно и сообщение в строчку склеить при желании. Язык С-образный, с его освоением никаких проблем нет. Со строками он работает вполне замечательно.

Кстати, сообщения об ошибках в несколько строк - это редкость. Кроме ИАРа я такого нигде не видел. И это, кстати, тоже не их изобретение: когда это только появилось и стало анноить, я спросил, зачем так сделали - ведь неудобно же во внешних тулза получается. А они сказали, что это, дескать, так делает front-end, который они юзают (от EDG). Но в следующей версии по просьбе ввели этот самый ключ, который теперь есть во всех версиях и проблем нет. Т.ч. компилятор, который безвозвратно выдает сообщение об ошибке в несколько строк, еще поискать. Я такого не знаю. Может ты знаешь?

Hello, Harry Zhurov !

По меньшей мере 8 лет назад, я знал, так как добавлял в свой обработчик компиляторного выхода соответствующие regexp макросы (программа была под DOS и звалась CONNECT). Hе исключено, что это и был IAR для 8051 тех лет. Кстати, прошу заметить, что идея задавать шаблоны для определения имени файла/строки в нем/позиции в ней регулярными выражениями была мною _реализована_ в программерском редакторе еще минимум 8 лет назад (лень лазить по своему whatsnew.txt в поисках когда же это на самом деле было реализовано.

С уважением, Дима Орлов.

PS Впрочем решил посмотеть:

• Добавлены макросы $UP() и $DOWN() в фильтры Filename mask и Line num mask в Viewer list, File associations и Program list и новый фильтр $POS(). Фильтр $POS() имеет один аргумент в виде регулярного выражения, заключенного в " " и возвращает позицию аргумента в строке. Макросы $UP() и $DOWN() имеют один параметр в виде числа строк в окне Message, на которые нужно подняться или опуститься перед применением фильтра, их содержащего. Так, например, для Turbo Pascal информация, выводимая ком- пилятором об ошибках, выглядит следующим образом:

E:\WORK\CONNECT\1.PAS(2): Error 3: Unknown identifier. kjhgkug ^ Для того, чтобы стоя курсором на строке, содержащей ошибку, можно было открыть окно с файлом, ее вызвавшим, надо написать:

Filename mask $UP(1)$COPY(1,"(") Line num mask $UP(1)$COPY("(",")"):$DOWN(1)$POS("\^")

Hello Andy.

AM> А как ты запyскаешь pазные компилятоpы? AM> Обычно (во всяком слyчае я дyмаю, так должно быть) regexp должен AM> пpивязываться к запyскy опpеделенного конкpетного tool.

AM> С pедактоpом компилятоp/ассемблеp/линкеp связываются чеpез меню AM> внешних инстpyментов (не сyть важно конкpетное название этого AM> механизма AM> в конкpетном pедактоpе). AM> Для каждого инстpyмента пpописывается свой regexp. AM> Если ты вызываешь компилятоp IAR C для AVR, то емy пpописывается один AM> regexp. Если ты захотел gcc - дpyгой, если keil x51 - тpетий, и т.п. AM> Также ассемблеpы и линкеpы имеют свои regexp. То есть regexp для паpсинга AM> - это пpинадлежность конкpетного tool, а не yнивеpсальная и единственная AM> настpойка для всех внешних тyлзов. AM> Это логично, посколькy сообщения компилятоpом не стандаpтизиpованы. AM> Hеyжели Slick не yмеет pазделять regexp по тyлзам? Что-то сомневаюсь.

Механизм такой: при создании проекта, ты говоришь каким "package" ты будешь пользоваться. Здесь уже может быть много regexp-ов например для ассеблера и C-компилятора

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

Сликкеристы, к сожалению, выбрали свои главные направления, и на них кидают все силы:

MSDEV , JAVA .NET

У них забот хватает на этих направлениях.

Alexey

Hello Harry.

HZ>>> Hадо почитать доку, в которой описан ключ --no_wrap_diagnostics, HZ>>> который означает "Don't wrap long lines in diagnostic messages". Все HZ>>> выдается в одну строку.

AG>> Мы ж обсуждаем возможности технологии сликкера. AG>> А если в компиллере нет возможности изменить формат вывода? AG>> Я ж IAR привел для примера.

HZ> Если мы обсуждаем возможности слика, то замечу, что у него есть HZ> встроенный язык Slick-C, на котором реализована вся функциональность. И на HZ> нем в том числе можно и сообщение в строчку склеить при желании. Язык HZ> С-образный, с его освоением никаких проблем нет. Со строками он работает HZ> вполне замечательно.

Писать на макросах сликкера менее удобно чем на C++. ( Хотя макросы для сликкера пишу регулярно ). Опять же непонятно как сделать удобным переключение макросов для разных компиляторов.

HZ> Кстати, сообщения об ошибках в несколько строк - это редкость. HZ> Кроме HZ> ИАРа я такого нигде не видел. И это, кстати, тоже не их изобретение: когда HZ> это только появилось и стало анноить, я спросил, зачем так сделали - ведь HZ> неудобно же во внешних тулза получается. А они сказали, что это, дескать, HZ> так делает front-end, который они юзают (от EDG). Hо в следующей версии по HZ> просьбе ввели этот самый ключ, который теперь есть во всех версиях и HZ> проблем нет. Т.ч. компилятор, который безвозвратно выдает сообщение об HZ> ошибке в несколько строк, еще поискать. Я такого не знаю. Может ты знаешь?

Я бы не стал акцентировать внимание только на этом.

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

- выводят в stdout (или в stderr) фиг знает чем, так что, не перехватить... - форматы меняют для разного рода ошибок - выводят ошибку без строки ( ошибка может потом пропуститься макросом next_error)

Это то, что я вспомнил сразу.

Alexey