На Sat, 10 Nov 2007 00:43:11 +0300
"Dmitry E. Oboukhov" <[EMAIL PROTECTED]> записано:
> или из простого бинарника функции не перехватить?
Да, естественно, LD_PRELOAD - это хак на уровне shared библиотек.
Обычно библиотека подгружается при первом использовании функции, а этот
хак заставляет заране
On Sat, Nov 10, 2007 at 12:43:11AM +0300, Dmitry E. Oboukhov wrote:
> > есть libconnect в портах freebsd - там перехватывается connect(2), дабы
> > сделать
> > bind(2) на локальную сторону сокета (bind адрес берется из переменной
> > окружения
> > CONN_ADDR). используется так:
>
> набросал такой
"Dmitry E. Oboukhov" <[EMAIL PROTECTED]> writes:
> чтоб это все потребовалось доказывать нужна пострадавшая сторона
> которая иски учинять будет :)
Российские госструктуры взяли на себя расширенные и углубленные
обязательства: покарать "виновного", не дожидаясь заявления пострадавшей
стороны. Вид
09.11.07, Dmitry E. Oboukhov<[EMAIL PROTECTED]> написал(а):
> чтоб это все потребовалось доказывать нужна пострадавшая сторона которая
> иски учинять будет :)
По слухам из интернета (ссылку потерял, найти не смог :)
в этой области это уже не так - пострадавшая сторона не нужна.
> есть libconnect в портах freebsd - там перехватывается connect(2), дабы
> сделать
> bind(2) на локальную сторону сокета (bind адрес берется из переменной
> окружения
> CONN_ADDR). используется так:
> export LD_PRELOAD=/usr/local/lib/libconnect.so
> export CONN_ADDR=1.2.3.4
> ./program --op1 --
Интересный вы вопрос подняли. С юридической точки зрения, разумеется. В
результате халатности работодателя и работника потеряны исходные коды
программы, закон такую ситуацию ну никак не предусматривает. Собственно,
программу следует ставить на баланс предприятия, тогда и вопросов не будет,
вот
>> тут никаких противозаконных действий: имеетс софтина которая писалась
>> наемным программером, тот уволился, исходники потом потерялись т.к. были
>> никому неинтересны
> Для меня это достаточное объяснение, а вот с точки зрения закона авторские
> права _всегда_ принадлежат разработчику (имущест
> тут никаких противозаконных действий: имеетс софтина которая писалась
> наемным программером, тот уволился, исходники потом потерялись т.к. были
> никому неинтересны
Для меня это достаточное объяснение, а вот с точки зрения закона авторские
права _всегда_ принадлежат разработчику (имущественные
>>> задача стоит в том что надо пропатчить бинарник.
>>> исходника нет :)
>>> необходимая функция gdb находится а вот дальше как перейти к файлу
>>> elf?
>>
>> Вспоминая про российские и международные законы, лучше на самом деле
>> переформул
09.11.07, Dmitry E. Oboukhov<[EMAIL PROTECTED]> написал(а):
> >> задача стоит в том что надо пропатчить бинарник.
> >> исходника нет :)
> >> необходимая функция gdb находится а вот дальше как перейти к файлу elf?
>
> > Помучай readelf.
>
> спасибо
09.11.07, Dmitry E. Oboukhov<[EMAIL PROTECTED]> написал(а):
> > На сколько я знаю такой зависимости не существует.
> мне интересно бы было посмотреть что там с адресами на платформах а-ля
> AMD64, но на всех моих AMD64 стоит i386 Debian.
>
> если у кого есть и AMD64 и i386 и разные дистры - мог бы
В сообщении от Friday 09 November 2007 20:36:13 Alexander GQ Gerasiov
написал(а):
> На Fri, 9 Nov 2007 17:46:17 +0300
>
> Alexey Pechnikov <[EMAIL PROTECTED]> записано:
> > > задача стоит в том что надо пропатчить бинарник.
> > > исходника нет :)
> > &g
На Fri, 9 Nov 2007 17:46:17 +0300
Alexey Pechnikov <[EMAIL PROTECTED]> записано:
> > задача стоит в том что надо пропатчить бинарник.
> > исходника нет :)
> > необходимая функция gdb находится а вот дальше как перейти к файлу
> > elf?
>
> Вспоминая про российс
bbfd.
>>> Но лучше переформулировать задачу.
>> задача стоит в том что надо пропатчить бинарник.
>> исходника нет :)
>> необходимая функция gdb находится а вот дальше как перейти к файлу elf?
>>
> возможно на это посмотреть иначе. это не совсем то, что вам хочетс
> > Готовых нет. Написать самому, используя libbfd.
> > Но лучше переформулировать задачу.
> задача стоит в том что надо пропатчить бинарник.
> исходника нет :)
> необходимая функция gdb находится а вот дальше как перейти к файлу elf?
>
возможно на это посмотреть иначе. это не
>> задача стоит в том что надо пропатчить бинарник.
>> исходника нет :)
>> необходимая функция gdb находится а вот дальше как перейти к файлу elf?
> Помучай readelf.
спасибо посмотрю
> А поиском кода по файлу не проще будет?
поиском находится несколько мест, а функция о
В сообщении от п'ятниця, 09-лис-2007 Dmitry E. Oboukhov написал(a):
> задача стоит в том что надо пропатчить бинарник.
> исходника нет :)
> необходимая функция gdb находится а вот дальше как перейти к файлу elf?
Помучай readelf.
А поиском кода по файлу не проще будет?
>> задача стоит в том что надо пропатчить бинарник.
>> исходника нет :)
>> необходимая функция gdb находится а вот дальше как перейти к файлу elf?
> Вспоминая про российские и международные законы, лучше на самом деле
> переформулировать задачу. А то статья свет
> задача стоит в том что надо пропатчить бинарник.
> исходника нет :)
> необходимая функция gdb находится а вот дальше как перейти к файлу elf?
Вспоминая про российские и международные законы, лучше на самом деле
переформулировать задачу. А то статья светит.
задача стоит в том что надо пропатчить бинарник.
исходника нет :)
необходимая функция gdb находится а вот дальше как перейти к файлу elf?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
09.11.07, Dmitry E. Oboukhov<[EMAIL PROTECTED]> написал(а):
> >>> как адрес функции который выдает gdb преобразовать в смещение от начала
> >>> elf-файла?
> >>
> > Нет. Разбирать структуру elf-файла (bfd) и искать там функцию по имени.
> есть ли ту
>>> как адрес функции который выдает gdb преобразовать в смещение от начала
>>> elf-файла?
>>
>> Судя по всему никак. То ж адрес в памяти, который зависим от состояния
>> памяти на момент выделения. Может капнуть в сторону man dlopen:
> Нет. Разбирать
> На сколько я знаю это не правда. Тот эффект, который вы наблюдаете - это
> либо между вызовами Вашей программы состояние памяти не сильно меняется
> и Ваша программа грузится в одно и то же место, либо это результат
> работы файлового кэша. Попробуйте запомнить адрес, перегрузиться,
> запустить н
В Птн, 09/11/2007 в 16:38 +0300, Dmitry E. Oboukhov пишет:
> >> как адрес функции который выдает gdb преобразовать в смещение от начала
> >> elf-файла?
>
> > Судя по всему никак. То ж адрес в памяти, который зависим от состояния
> > памяти на момент выделения. М
>> как адрес функции который выдает gdb преобразовать в смещение от начала
>> elf-файла?
> Судя по всему никак. То ж адрес в памяти, который зависим от состояния
> памяти на момент выделения. Может капнуть в сторону man dlopen:
насколько я понимаю все программы с одного адре
2007/11/9, Покотиленко Костик <[EMAIL PROTECTED]>:
> В Птн, 09/11/2007 в 12:56 +0300, Dmitry E. Oboukhov пишет:
> > как адрес функции который выдает gdb преобразовать в смещение от начала
> > elf-файла?
>
> Судя по всему никак. То ж адрес в памяти, который зависим от с
В Птн, 09/11/2007 в 12:56 +0300, Dmitry E. Oboukhov пишет:
> как адрес функции который выдает gdb преобразовать в смещение от начала
> elf-файла?
Судя по всему никак. То ж адрес в памяти, который зависим от состояния
памяти на момент выделения. Может капнуть в сторону man dlopen:
...
как адрес функции который выдает gdb преобразовать в смещение от начала
elf-файла?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On 2006.11.28 at 01:09:00 +, Mikhail Ramendik wrote:
> Всем привет!
>
> По здешнему совету поставил kdepim-dbg. После этого поймал зависание,
> приаттачил gdb и сдал делать bt во всех тредах.
>
> К сожалению, не очень понятно, полностью ли он находит эти самыпе debug
Mikhail Ramendik wrote:
> Всем привет!
>
> По здешнему совету поставил kdepim-dbg. После этого поймал зависание,
> приаттачил gdb и сдал делать bt во всех тредах.
>
> К сожалению, не очень понятно, полностью ли он находит эти самыпе debugging
> symbols. В бектрейс
28.11.06, Mikhail Ramendik<[EMAIL PROTECTED]> написал(а):
Всем привет!
По здешнему совету поставил kdepim-dbg. После этого поймал зависание,
приаттачил gdb и сдал делать bt во всех тредах.
К сожалению, не очень понятно, полностью ли он находит эти самыпе debugging
symbols. В бектрейсах
Всем привет!
По здешнему совету поставил kdepim-dbg. После этого поймал зависание,
приаттачил gdb и сдал делать bt во всех тредах.
К сожалению, не очень понятно, полностью ли он находит эти самыпе debugging
symbols. В бектрейсах нечто вроде такого:
thread 1:
#0 0xb7f2b410 in ?? ()
#1
You ([EMAIL PROTECTED]) wrote:
MG>> Ну скажи ещё, что всё это не распространяется на общающиеся
MG>> между собой процессы, разделяющие файловую систему или что-либо
MG>> ещё.
AC> Распространяется. Но там гораздо сложнее нарушить протокол.
На этом можно и закончить, ибо "сложнее/не сложнее"
Anton Petrusevich -> debian-russian@lists.debian.org @ Tue, 28 Mar 2006
17:48:17 +0200:
>> А, ну-ну... Хинт: чтобы это работало, надо построить _полную_ систему
>> этих самых правил. Доказать ее полноту и дать специально образованным
>> людям проверить доказательство. И после каждого измен
Mikhail Gusarov -> debian-russian@lists.debian.org @ Tue, 28 Mar 2006 22:32:37
+0700:
AC>> А, ну-ну... Хинт: чтобы это работало, надо построить _полную_
AC>> систему этих самых правил.Доказать ее полноту и дать специально
AC>> образованным людям проверить доказательство. И после каждого
AC
On Tuesday 28 March 2006 17:26, Artem Chuprina wrote:
> А, ну-ну... Хинт: чтобы это работало, надо построить _полную_ систему
> этих самых правил. Доказать ее полноту и дать специально образованным
> людям проверить доказательство. И после каждого изменения в программе
> проверять, не нарушили л
You ([EMAIL PROTECTED]) wrote:
AC> А, ну-ну... Хинт: чтобы это работало, надо построить _полную_
AC> систему этих самых правил.Доказать ее полноту и дать специально
AC> образованным людям проверить доказательство. И после каждого
AC> изменения в программе проверять, не нарушили ли где прото
Anton Petrusevich -> debian-russian@lists.debian.org @ Mon, 27 Mar 2006
17:26:44 +0100:
>> А высокоуровневые рассуждения, конечно, надежнее... Они, конечно,
>> доказываются и доказательства проверяют несколько хороших специалистов в
>> computer science? Каждый раз после малейшего изменения
Mikhail Gusarov -> debian-russian@lists.debian.org @ Mon, 27 Mar 2006 21:39:56
+0700:
AC>> А высокоуровневые рассуждения, конечно, надежнее... Они,
AC>> конечно, доказываются и доказательства проверяют несколько
AC>> хороших специалистов в computer science? Каждый раз после
AC>> малейшего
On Monday 27 March 2006 16:30, Artem Chuprina wrote:
> А высокоуровневые рассуждения, конечно, надежнее... Они, конечно,
> доказываются и доказательства проверяют несколько хороших специалистов в
> computer science? Каждый раз после малейшего изменения в программе?
Достаточно определить правила
You ([EMAIL PROTECTED]) wrote:
AC> А высокоуровневые рассуждения, конечно, надежнее... Они,
AC> конечно, доказываются и доказательства проверяют несколько
AC> хороших специалистов в computer science? Каждый раз после
AC> малейшего изменения в программе?
Да-да, а вы конечно проверяете, что
Anton Petrusevich -> debian-russian@lists.debian.org @ Fri, 24 Mar 2006
20:56:10 +0100:
>> Даже если ты с unit-тестами на ты, тебе придется гонять тесты часами,
>> чтобы отловить все возможные race condition. Поэтому с нитями надо
>> связываться только если очень приперло.
AP> Ой, а race co
В сообщении от 26 Март 2006 05:07 Dmitry Baryshkov написал(a):
> > я бы сказал - как вообще с помошью gdb можно отлаживать программы -
> > непонятно.
> Компиляцию для отладки с -O0 (максимум -O1) никто не отменял. Вы бы еще
> с -O3 -fomit-frame-pointer скомпилировали и пытали
Hello,
25.03.06, Andrey Melnikoff<[EMAIL PROTECTED]> написал(а):
> я бы сказал - как вообще с помошью gdb можно отлаживать программы -
> непонятно.
Компиляцию для отладки с -O0 (максимум -O1) никто не отменял. Вы бы еще
с -O3 -fomit-frame-pointer скомпилировали и пытались отлажива
hed нитку, если код возврата неинтересен. Сам
никогда семафорами не пользовался, только мутексами, на превый взгляд не
видно откуда возьмётся SIGSEGV, что говорит gdb по команде bt в этом случае?
Многопоточная отладка и правда довольно сложна -- управление может
передаваться другой нитке, что и про
Привет.
Всё гораздо интереснее стало: оказывается проблема возникает при отладке
под xterm. Т.е. запускаем xterm, в нём - gdb, ставим точки останова,
ходим по шагам, наблюдаем падения. При запуске под rxvt - всё в порядке.
Погуглил. На редхатовской багзиле несколько описаний почти идентичной
Vasily Titsky <[EMAIL PROTECTED]> wrote:
> Привет.
> Столкнулся со странным поведенем программы, запускаемой из отладчика
> (под gdb). Начал выяснять. Обнаружилось, что если в программе есть
> несколько нитей, то при "хождении по шагам" нити могут просыпаться,
> И даже не спрашивают, как отлаживать с нитями.
>
> А спрашивают - что за проблемы с нитями у gdb.
Генетически у него с ними проблемы. Он unix-овый по происхождению. А
нити в *nix сущность чуждая и поздно привнесенная. Соответственно,
механизм сигналов, на котором в значительной степени основана
You ([EMAIL PROTECTED]) wrote:
>> Возвращаясь к существу вопроса - пошаговая отладка в gdb
>> многопоточных приложений - возможна? Если да, то как? URL'ы, доки
>> и прочее - приветствуются.
D> Можно писать так чтоб меньше отлаживать...
Можно вообще не пис
25.03.06, Dmitry-T<[EMAIL PROTECTED]> написал(а):
> Можно писать так чтоб меньше отлаживать...
Дмитрий, вас не спрашивают, как лучше программировать - с нитями или
без, с какими либами и т.д.
И даже не спрашивают, как отлаживать с нитями.
А спрашивают - что за проблемы с нитями у gdb.
On Sat, 25 Mar 2006 01:08:30 +0300
Vasily Titsky <[EMAIL PROTECTED]> wrote:
> Возвращаясь к существу вопроса - пошаговая отладка в gdb многопоточных
> приложений - возможна? Если да, то как? URL'ы, доки и прочее -
> приветствуются.
Можно писать так чтоб меньше отлаж
только если очень приперло.
Я (скоро уже десять лет как программист встроенных систем реального
времени), прочитал это с большим интересом :)
Возвращаясь к существу вопроса - пошаговая отладка в gdb многопоточных
приложений - возможна? Если да, то как? URL'ы, доки и прочее -
приветств
On Friday 24 March 2006 20:35, Victor Wagner wrote:
> Даже если ты с unit-тестами на ты, тебе придется гонять тесты часами,
> чтобы отловить все возможные race condition. Поэтому с нитями надо
> связываться только если очень приперло.
Ой, а race condition ловят тестами? Уж больно ненадёжно как-то.
On 2006.03.24 at 21:53:04 +0300, Vasily Titsky wrote:
> Всё. Приплыли. Как вообще можно отлаживать программы - непонятно.
Сначала надо научиться писать программы, так чтобы их не нужно было
отлажвать в интерактивном отладчике, потом научиться писать к ним
полномасштабные test suite, и только пот
Привет.
Столкнулся со странным поведенем программы, запускаемой из отладчика
(под gdb). Начал выяснять. Обнаружилось, что если в программе есть
несколько нитей, то при "хождении по шагам" нити могут просыпаться, хотя
они сидят на вызове sem_wait(&sema), а сам "sema&q
Hi,
В общем, немножко офтопик - но надеюсь на помощь.
Пользую в консоли gnu emacs 21.2.1, в нем - GUD (интерфейс к gdb) -
для отлаживания программ на С++.
При трассировке (шаганию по строкам) экран разделяется на 2 буфера - в одном
- комм. строка gdb, в другой - исх код. При переключении в
On Thu, 17 Jan 2002, DEVI[Low] wrote:
Hi,
В первую очередь - какая версия gdb? Если не 5.x - то настоятельно рекомендую
поставить 5.x - он по-нормальному поддерживает отладку многопоточных программ.
>
> // --from: [EMAIL PROTECTED]
> // --addr: debian-russian@lists.d
// --from: [EMAIL PROTECTED]
// --addr: debian-russian@lists.debian.org
// --date: 17 января 2002 г. 23:34:42
// --subj: gdb & break & thread's ...
Hi, debian-russian ...
может всезнающий all подскажет чего мудрого ...
есть программка, которая состоит
Все могло упасть не в твоем коде. Например, если такая штука происходит в
startup-коде, или в пострипанной системной библиотеке -- симптомы должны быть
похожи. Это еще если не брать варианты порчи стека или перехода по
неправильному адресу.
--cdi
On Thu, Oct 12, 2000 at 08:50:12PM +0400, Alexand
On Thu, Oct 12, 2000 at 05:46:42PM +0400, Michael Sobolev wrote:
> On Thu, Oct 12, 2000 at 02:36:01PM +0200, Iouri Nefedov wrote:
> > > > #0 0x5f5e5bd8 in ?? ()
>
> > > Отсутствие отладочной информации?
> > Возможно, что использовали strip - discard symbols from object files.
> Кстати, да. :)
д
On Thu, Oct 12, 2000 at 02:36:01PM +0200, Iouri Nefedov wrote:
> > > #0 0x5f5e5bd8 in ?? ()
> > Отсутствие отладочной информации?
> Возможно, что использовали strip - discard symbols from object files.
Кстати, да. :)
--
Миша
On Thu, 12 Oct 2000, Michael Sobolev wrote:
> On Thu, Oct 12, 2000 at 02:24:18PM +0400, Alexander Kotelnikov wrote:
> > Что бы т могло значить:
> > ---
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x5f5e5bd8 in ?? ()
> > (gdb) bt
> > #0 0
On Thu, Oct 12, 2000 at 02:24:18PM +0400, Alexander Kotelnikov wrote:
> Что бы т могло значить:
> ---
> Program received signal SIGSEGV, Segmentation fault.
> 0x5f5e5bd8 in ?? ()
> (gdb) bt
> #0 0x5f5e5bd8 in ?? ()
> ---
Отсутствие отладочной информации?
--
Миша
Что бы т могло значить:
---
Program received signal SIGSEGV, Segmentation fault.
0x5f5e5bd8 in ?? ()
(gdb) bt
#0 0x5f5e5bd8 in ?? ()
---
?
Спасибо,
--
Alexander Kotelnikov
Saint-Petersburg, Russia
64 matches
Mail list logo
