[sisyphus] C++ & gdb

[sisyphus] C++ & gdb

[Alexey Morozov]

Скажите, а кто чем отлаживает программы на C++? gdb, по-моему,
достаточно ущербный в этом плане. Во всяком случае, с задачей показа
содержимого объектов сложных классов он практически не справляется.
У меня тут библиотечка, написанная в ATL'ном стиле, показ любого
сколько-нибудь сложного объекта кончается примерно так:

(gdb) display p
1: p = {<raw_packet_ptr<server::dgram::packet>> = {
    p = 0x80688d8}, <No data fields>}
gdb) display p.p
2: p.p = (packet *) 0x80688d8
(gdb) display *p.p
3: *p.p = Value can't be converted to integer.
Disabling display 3 to avoid infinite recursion.
(gdb) _
Хотя ptype на *p.p вполне себе работает.
Это как-нибудь лечится или таки в морг. А если в морг - то чем ведущие
собаководы пользуются для подобных целей? А то ведь рядом сидит дружок
на MSVC6 - и вовсю все эти структуры данных просматривает и прочее...
Прям хоть на винде сервер разрабатывай...

Re: [sisyphus] C++ & gdb

[Sanja Byelkin]

Привет!

On Mon, Sep 23, 2002 at 11:50:44AM +0700, Alexey Morozov wrote:
> Скажите, а кто чем отлаживает программы на C++? gdb, по-моему,
> достаточно ущербный в этом плане. Во всяком случае, с задачей показа
> содержимого объектов сложных классов он практически не справляется.
> У меня тут библиотечка, написанная в ATL'ном стиле, показ любого
> сколько-нибудь сложного объекта кончается примерно так:
> 
> (gdb) display p
> 1: p = {<raw_packet_ptr<server::dgram::packet>> = {
>     p = 0x80688d8}, <No data fields>}
> gdb) display p.p
> 2: p.p = (packet *) 0x80688d8
> (gdb) display *p.p
> 3: *p.p = Value can't be converted to integer.
> Disabling display 3 to avoid infinite recursion.
> (gdb) _
> Хотя ptype на *p.p вполне себе работает.
> Это как-нибудь лечится или таки в морг. А если в морг - то чем ведущие
> собаководы пользуются для подобных целей? А то ведь рядом сидит дружок
> на MSVC6 - и вовсю все эти структуры данных просматривает и прочее...
> Прям хоть на винде сервер разрабатывай...

Я ddd использую - это как-бы графическая надстройка над gdb (и еще
некоторыми редакторами) - смотрит все (при помощи того-же gdb, но как - я 
не знаю).

У меня с местным gdb другие проблемы - отладка в multithread. Временно
полечилось нестатической линковкой но (наверно после очередного обновления)
опять поплохело. Но я твердо увекрен что 1) проблема местная 2) частые
обновления оказалось тоже зло :)  3) прийдется что-то менять.

-- 
Regards,
Alexander

Re: [sisyphus] C++ & gdb

[Alexey Morozov]

On Mon, Sep 23, 2002 at 09:11:52AM +0300, Sanja Byelkin wrote:
> > Скажите, а кто чем отлаживает программы на C++? gdb, по-моему,
> > достаточно ущербный в этом плане. Во всяком случае, с задачей показа
> > содержимого объектов сложных классов он практически не справляется.
> > У меня тут библиотечка, написанная в ATL'ном стиле, показ любого
> > сколько-нибудь сложного объекта кончается примерно так:
> > 
> > (gdb) display p
> > 1: p = {<raw_packet_ptr<server::dgram::packet>> = {
> >     p = 0x80688d8}, <No data fields>}
> > gdb) display p.p
> > 2: p.p = (packet *) 0x80688d8
> > (gdb) display *p.p
> > 3: *p.p = Value can't be converted to integer.
> > Disabling display 3 to avoid infinite recursion.
> > (gdb) _
> > Хотя ptype на *p.p вполне себе работает.
> > Это как-нибудь лечится или таки в морг. А если в морг - то чем ведущие
> > собаководы пользуются для подобных целей? А то ведь рядом сидит дружок
> > на MSVC6 - и вовсю все эти структуры данных просматривает и прочее...
> > Прям хоть на винде сервер разрабатывай...
> Я ddd использую - это как-бы графическая надстройка над gdb (и еще
> некоторыми редакторами) - смотрит все (при помощи того-же gdb, но как - я 
> не знаю).
Да ddd-то ничем не поможет в моем случае. Команда graph display <smth>
ничем не лучше display <smth>, то есть, как не работало, так и не
работает. Собственно, изначально я ddd и пускал...

> У меня с местным gdb другие проблемы - отладка в multithread. Временно
> полечилось нестатической линковкой но (наверно после очередного обновления)
> опять поплохело. Но я твердо увекрен что 1) проблема местная 2) частые
> обновления оказалось тоже зло :)  3) прийдется что-то менять.
Поищите в инете "Smart GDB". Правда, сдается мне, проект сдох года два
как... Но вдруг...

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Mon, Sep 23, 2002 at 11:50:44AM +0700, Alexey Morozov wrote:
> Скажите, а кто чем отлаживает программы на C++? gdb, по-моему,
> достаточно ущербный в этом плане. Во всяком случае, с задачей показа
> содержимого объектов сложных классов он практически не справляется.
> У меня тут библиотечка, написанная в ATL'ном стиле, показ любого
> сколько-нибудь сложного объекта кончается примерно так:
> 
> (gdb) display p
> 1: p = {<raw_packet_ptr<server::dgram::packet>> = {
>     p = 0x80688d8}, <No data fields>}
> gdb) display p.p
> 2: p.p = (packet *) 0x80688d8
> (gdb) display *p.p
> 3: *p.p = Value can't be converted to integer.
> Disabling display 3 to avoid infinite recursion.
> (gdb) _
> Хотя ptype на *p.p вполне себе работает.
> Это как-нибудь лечится или таки в морг. А если в морг - то чем ведущие

Я не сталкивался.
Поэтому давайте testcase.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Vlad Harchev]

On Mon, 23 Sep 2002, Alexey Morozov wrote:

> Скажите, а кто чем отлаживает программы на C++? gdb, по-моему,
> достаточно ущербный в этом плане. Во всяком случае, с задачей показа
> содержимого объектов сложных классов он практически не справляется.
> У меня тут библиотечка, написанная в ATL'ном стиле, показ любого
> сколько-нибудь сложного объекта кончается примерно так:
> 
> (gdb) display p
> 1: p = {<raw_packet_ptr<server::dgram::packet>> = {
>     p = 0x80688d8}, <No data fields>}
> gdb) display p.p
> 2: p.p = (packet *) 0x80688d8
> (gdb) display *p.p
> 3: *p.p = Value can't be converted to integer.
> Disabling display 3 to avoid infinite recursion.
> (gdb) _
> Хотя ptype на *p.p вполне себе работает.
> Это как-нибудь лечится или таки в морг. А если в морг - то чем ведущие
> собаководы пользуются для подобных целей? А то ведь рядом сидит дружок
> на MSVC6 - и вовсю все эти структуры данных просматривает и прочее...
> Прям хоть на винде сервер разрабатывай...

 Глупый вопрос - а программа собрана с -g3?
 А gdb какой версии?
 А если попробовать то же самое скомпилить и поотлаживать под rh73? (Может
программа собрана gcc-3.x а он генерит инфу о типах в немного непонятном
формате для gdb или в rh какие-либо выпрямляющие патчи приложены?)

 Best regards,
  -Vlad

Re: [sisyphus] C++ & gdb

[Vitaly Lugovsky]

On Mon, 23 Sep 2002, Alexey Morozov wrote:

> Скажите, а кто чем отлаживает программы на C++?

 Как я многократно повторял, так называемые "дебаггеры",
вроде всяких там gdb, для отладки ни разу не годятся.
Правильный подход к отладке - ассерты, логи и формальное доказательство 
для особо гадского кода. Итерационный же дебаг - лишь источник новых, 
трудноуловимых ошибок. И, кстати, C++ - суксь.

Re: [sisyphus] C++ & gdb

[Alexey Morozov]

On Mon, Sep 23, 2002 at 02:22:25PM +0500, Vlad Harchev wrote:
> > на MSVC6 - и вовсю все эти структуры данных просматривает и прочее...
> > Прям хоть на винде сервер разрабатывай...
>  Глупый вопрос - а программа собрана с -g3?
Да.
>  А gdb какой версии?
5.1.1-alt1
>  А если попробовать то же самое скомпилить и поотлаживать под rh73? (Может
> программа собрана gcc-3.x а он генерит инфу о типах в немного непонятном
> формате для gdb или в rh какие-либо выпрямляющие патчи приложены?)
Еще не пробовал. Попробую, спасибо за идею...

Re: [sisyphus] C++ & gdb

[Alexey Morozov]

On Mon, Sep 23, 2002 at 12:20:44PM +0400, Dmitry V. Levin wrote:
> > gdb) display p.p
> > 2: p.p = (packet *) 0x80688d8
> > (gdb) display *p.p
> > 3: *p.p = Value can't be converted to integer.
> > Disabling display 3 to avoid infinite recursion.
> > (gdb) _
> > Хотя ptype на *p.p вполне себе работает.
> > Это как-нибудь лечится или таки в морг. А если в морг - то чем ведущие
> Я не сталкивался.
> Поэтому давайте testcase.
Хорошо, попытаюсь вычленить суть происходящего, сам код под NDA и все
такое.

Re: [sisyphus] C++ & gdb

[Alexey Morozov]

On Mon, Sep 23, 2002 at 03:06:50PM +0400, Vitaly Lugovsky wrote:
>  Как я многократно повторял, так называемые "дебаггеры",
> вроде всяких там gdb, для отладки ни разу не годятся.
> Правильный подход к отладке - ассерты, логи и формальное доказательство 
> для особо гадского кода. Итерационный же дебаг - лишь источник новых, 
> трудноуловимых ошибок. И, кстати, C++ - суксь.
Виталий, я ценю Ваше мнение в области использования программных средств
и все такое, но сейчас мне не очень интересно обсуждать эту тему. В
будущем, возможно, я подискутирую с Вами, но будет это будет не сейчас,
и, предположительно в r.o.c., а не здесь :-)
Пока же спасибо за комментарий и остановимся на этом.

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Mon, Sep 23, 2002 at 07:33:46PM +0700, Alexey Morozov wrote:
> > > на MSVC6 - и вовсю все эти структуры данных просматривает и прочее...
> > > Прям хоть на винде сервер разрабатывай...
> >  Глупый вопрос - а программа собрана с -g3?
> Да.
> >  А gdb какой версии?
> 5.1.1-alt1

Попробуйте gdb-5.2.1

> >  А если попробовать то же самое скомпилить и поотлаживать под rh73? (Может
> > программа собрана gcc-3.x а он генерит инфу о типах в немного непонятном
> > формате для gdb или в rh какие-либо выпрямляющие патчи приложены?)
> Еще не пробовал. Попробую, спасибо за идею...

У нас и RH gcc/gdb в значительной степени синхронизированы.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Sanja Byelkin]

Доброе время суток!

On Mon, Sep 23, 2002 at 04:42:44PM +0400, Dmitry V. Levin wrote:
[skip]
> Попробуйте gdb-5.2.1
> 
> > >  А если попробовать то же самое скомпилить и поотлаживать под rh73? (Может
> > > программа собрана gcc-3.x а он генерит инфу о типах в немного непонятном
> > > формате для gdb или в rh какие-либо выпрямляющие патчи приложены?)
> > Еще не пробовал. Попробую, спасибо за идею...
> 
> У нас и RH gcc/gdb в значительной степени синхронизированы.

А вы так и не попробовали глянуть на это чудо в multithread (как давно
обещали)?
(было время gdb нормально работал с динамически линкованным mysql, Теперь не
хочет и этого (gdb-5.2.1))

-- 
Regards,
Alexander

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Mon, Sep 23, 2002 at 04:28:31PM +0300, Sanja Byelkin wrote:
> > Попробуйте gdb-5.2.1
> > 
> > > >  А если попробовать то же самое скомпилить и поотлаживать под rh73? (Может
> > > > программа собрана gcc-3.x а он генерит инфу о типах в немного непонятном
> > > > формате для gdb или в rh какие-либо выпрямляющие патчи приложены?)
> > > Еще не пробовал. Попробую, спасибо за идею...
> > 
> > У нас и RH gcc/gdb в значительной степени синхронизированы.
> 
> А вы так и не попробовали глянуть на это чудо в multithread (как давно
> обещали)?
> (было время gdb нормально работал с динамически линкованным mysql, Теперь не
> хочет и этого (gdb-5.2.1))

Буквально на прошлой неделе отлаживал MySQL-server-3.23.52-alt1 именно в
multithread (на тему stack overflow). Никаких проблем с gdb-5.2.1-alt1, за
исключением того, что в этом режиме он не отслеживает динамически
подгружаемые разделяемые библиотеки.

Если у вас не работает, напишите, как это можно воспроизвести.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Sanja Byelkin]

Доброе время суток:

On Mon, Sep 23, 2002 at 05:42:41PM +0400, Dmitry V. Levin wrote:
> Буквально на прошлой неделе отлаживал MySQL-server-3.23.52-alt1 именно в
> multithread (на тему stack overflow). Никаких проблем с gdb-5.2.1-alt1, за
> исключением того, что в этом режиме он не отслеживает динамически
> подгружаемые разделяемые библиотеки.
> 
> Если у вас не работает, напишите, как это можно воспроизвести.

собирается mysql 4.0 из bk репозитария (с помощью BUILD/compile-pentium-debug)
cd mysql-test
./mysql-test-run --ddd
ставится break point допустим на mysql_execute_command
run
потучаем что-то типа:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x2aba4819 in sigsuspend () from /lib/libc.so.6
совсем не то, что хотелось :(

-- 
Regards,
Alexander

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Mon, Sep 23, 2002 at 04:53:36PM +0300, Sanja Byelkin wrote:
> > Буквально на прошлой неделе отлаживал MySQL-server-3.23.52-alt1 именно в
> > multithread (на тему stack overflow). Никаких проблем с gdb-5.2.1-alt1, за
> > исключением того, что в этом режиме он не отслеживает динамически
> > подгружаемые разделяемые библиотеки.
> > 
> > Если у вас не работает, напишите, как это можно воспроизвести.
> 
> собирается mysql 4.0 из bk репозитария (с помощью BUILD/compile-pentium-debug)
> cd mysql-test
> ./mysql-test-run --ddd
> ставится break point допустим на mysql_execute_command
> run
> получаем что-то типа:
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x2aba4819 in sigsuspend () from /lib/libc.so.6
> совсем не то, что хотелось :(

Почему же? Достаточно переключиться в нужный thread (см. info threads
при получении прерывания).


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Sanja Byelkin]

Доброго времени суток! 

On Mon, Sep 23, 2002 at 06:00:06PM +0400, Dmitry V. Levin wrote:
> Почему же? Достаточно переключиться в нужный thread (см. info threads
> при получении прерывания).

1. info threads ничего не находит
2. можно подробнее где искать
3. по воспоминаниям как оно работало в ASP-linux, действительно gdb
регулярно сообщал, что переключается на thred такой-то местный этого делать
не хочет - осталось выяснить как заставить местный (если вообще возможно :)


-- 
Regards,
Alexander

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Mon, Sep 23, 2002 at 05:11:19PM +0300, Sanja Byelkin wrote:
> > Почему же? Достаточно переключиться в нужный thread (см. info threads
> > при получении прерывания).
> 
> 1. info threads ничего не находит
> 2. можно подробнее где искать

info gdb, на тему "Debugging programs with multiple threads".

> 3. по воспоминаниям как оно работало в ASP-linux, действительно gdb
> регулярно сообщал, что переключается на thred такой-то местный этого делать
> не хочет - осталось выяснить как заставить местный (если вообще возможно :)

Думаю, что так же.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Sanja Byelkin]

Боброго времени суток!

On Mon, Sep 23, 2002 at 06:45:26PM +0400, Dmitry V. Levin wrote:
> On Mon, Sep 23, 2002 at 05:11:19PM +0300, Sanja Byelkin wrote:
> > > Почему же? Достаточно переключиться в нужный thread (см. info threads
> > > при получении прерывания).
> > 
> > 1. info threads ничего не находит
> > 2. можно подробнее где искать
> 
> info gdb, на тему "Debugging programs with multiple threads".
> 
> > 3. по воспоминаниям как оно работало в ASP-linux, действительно gdb
> > регулярно сообщал, что переключается на thred такой-то местный этого делать
> > не хочет - осталось выяснить как заставить местный (если вообще возможно :)
> 
> Думаю, что так же.


Program received signal SIGTRAP, Trace/breakpoint trap.
0x2ac3ef6e in select () from /lib/libc.so.6
(gdb) info threads
(gdb) 

т.е. выбирать неизчего

Кроме того в доке сказано:
   Whenever GDB stops your program, due to a breakpoint or a signal, it
automatically selects the thread where that breakpoint or signal
happened.  GDB alerts you to the context switch with a message of the
form `[Switching to SYSTAG]' to identify the thread.

т.е. как-бы переключать и не надо - само переключить должно.

Кроме того:
   Whenever GDB detects a new thread in your program, it displays both
GDB's thread number and the target system's identification for the
thread with a message in the form ^[New SYSTAG]'.  SYSTAG is a thread
identifier whose form varies depending on the particular system.  For
example, on HP-UX, you see

     [New thread 2 (system thread 26594)]

when GDB notices a new thread.

Я видел эти предупреждения в gdb-5.1 из updateов ASPLinux 7.2 и не вижу
здесь.

Может быть SIG32 (не помню постоянных матюков о SIG32 от моего предыдущего 
отладчика) или еще какойнить сигнал не проключен куда надо по умолчанию или
еще чего - мне сказать трудно - я не разбирался в той мере с gdb, но не
работает.

-- 
For technical support contracts, visit https://order.mysql.com/
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Mr. Oleksandr Byelkin <sanja@mysql.com>
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB, Full-Time Developer
/_/  /_/\_, /___/\___\_\___/   Lugansk, Ukraine
       <___/   www.mysql.com

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Mon, Sep 23, 2002 at 08:59:53PM +0300, Sanja Byelkin wrote:
> > > > Почему же? Достаточно переключиться в нужный thread (см. info threads
> > > > при получении прерывания).
> > > 
> > > 1. info threads ничего не находит
> > > 2. можно подробнее где искать
> > 
> > info gdb, на тему "Debugging programs with multiple threads".
> > 
> > > 3. по воспоминаниям как оно работало в ASP-linux, действительно gdb
> > > регулярно сообщал, что переключается на thred такой-то местный этого делать
> > > не хочет - осталось выяснить как заставить местный (если вообще возможно :)
> > 
> > Думаю, что так же.
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x2ac3ef6e in select () from /lib/libc.so.6
> (gdb) info threads

Удалось воспроизвести.

Workaround:
1. установить пакет glibc-core-debug и
2. запускать gdb/ddd с LD_LIBRARY_PATH=/usr/lib/debug


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Sanja Byelkin]

Доброе (РЕАЛЬНО!!!) время суток!

On Mon, Sep 23, 2002 at 10:26:24PM +0400, Dmitry V. Levin wrote:
[skip]
> Удалось воспроизвести.
> 
> Workaround:
> 1. установить пакет glibc-core-debug и
> 2. запускать gdb/ddd с LD_LIBRARY_PATH=/usr/lib/debug

_ОГРОМНОЕ_ спасибо! это действительно помогло (осталось только подумать как
это пристроить удобнее - но это уже детали)

-- 
Regards,
Alexander

Re: [sisyphus] C++ & gdb

[Sanja Byelkin]

On Mon, Sep 23, 2002 at 10:57:18PM +0300, Sanja Byelkin wrote:
> Доброе (РЕАЛЬНО!!!) время суток!
> 
> On Mon, Sep 23, 2002 at 10:26:24PM +0400, Dmitry V. Levin wrote:
> [skip]
> > Удалось воспроизвести.
> > 
> > Workaround:
> > 1. установить пакет glibc-core-debug и
> > 2. запускать gdb/ddd с LD_LIBRARY_PATH=/usr/lib/debug
> 
> _ОГРОМНОЕ_ спасибо! это действительно помогло (осталось только подумать как
> это пристроить удобнее - но это уже детали)

В догонку - коментарий к glibc-core-debug IMHO лучше поменять - мне не 
надо вроде трассировать glibc, а пакет оказался нужен => 'only' там не 
совсем уместно. Что б далеко не лезть - вот текст о котором я говорю:

-----------------------------------------------------------------------------
This package contains shared libc core libraries with debugging information.
You need this only if you want to step into C library routines during
debugging. To use these libraries, you need to set
LD_LIBRARY_PATH=/usr/lib/debug
in your environment before starting debugger.
If you want to see glibc source files during debugging, you should
rpm -i glibc-2.2.6-alt0.2.src.rpm
rpm -bp %_specdir/glibc.spec
-----------------------------------------------------------------------------

-- 
Regards,
Alexander

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Mon, Sep 23, 2002 at 11:16:06PM +0300, Sanja Byelkin wrote:
> > > Удалось воспроизвести.
> > > 
> > > Workaround:
> > > 1. установить пакет glibc-core-debug и
> > > 2. запускать gdb/ddd с LD_LIBRARY_PATH=/usr/lib/debug
> > 
> > _ОГРОМНОЕ_ спасибо! это действительно помогло (осталось только подумать как
> > это пристроить удобнее - но это уже детали)
> 
> В догонку - коментарий к glibc-core-debug IMHO лучше поменять - мне не 
> надо вроде трассировать glibc, а пакет оказался нужен => 'only' там не 
> совсем уместно. Что б далеко не лезть - вот текст о котором я говорю:

Спасибо, принято.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

On Mon, Sep 23, 2002 at 10:57:18PM +0300, Sanja Byelkin wrote:
> Доброе (РЕАЛЬНО!!!) время суток!
> 
> On Mon, Sep 23, 2002 at 10:26:24PM +0400, Dmitry V. Levin wrote:
> [skip]
> > Удалось воспроизвести.
> > 
> > Workaround:
> > 1. установить пакет glibc-core-debug и
> > 2. запускать gdb/ddd с LD_LIBRARY_PATH=/usr/lib/debug
> 
> _ОГРОМНОЕ_ спасибо! это действительно помогло (осталось только подумать как
> это пристроить удобнее - но это уже детали)

Честно говоря, мне пока что не ясно, почему эту нужно делать для
многопоточных программ (для обычных - не нужно).
Возможно, в по'strip'анном libpthread удалена какая-то важная для gdb
информация. Если кто-нибудь в курсе, напишите.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]

On Tue, 24 Sep 2002 13:52:31 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> On Mon, Sep 23, 2002 at 10:57:18PM +0300, Sanja Byelkin wrote:
> > Доброе (РЕАЛЬНО!!!) время суток!
> > 
> > On Mon, Sep 23, 2002 at 10:26:24PM +0400, Dmitry V. Levin wrote:
> > [skip]
> > > Удалось воспроизвести.
> > > 
> > > Workaround:
> > > 1. установить пакет glibc-core-debug и
> > > 2. запускать gdb/ddd с LD_LIBRARY_PATH=/usr/lib/debug
> > 
> > _ОГРОМНОЕ_ спасибо! это действительно помогло (осталось только подумать как
> > это пристроить удобнее - но это уже детали)
> 
> Честно говоря, мне пока что не ясно, почему эту нужно делать для
> многопоточных программ (для обычных - не нужно).
> Возможно, в по'strip'анном libpthread удалена какая-то важная для gdb
> информация. Если кто-нибудь в курсе, напишите.

Я, кажется, понял, в чем дело. В gdb поддержка потоков теперь сделана
через libthread_db.so.1 (linuxthreads_db в glibc), а там в коде можно
обнаружить, например, следующее:

  /* Get the global event mask.  This is one of the variables which
     are new in the thread library to enable debugging.  If it is
     not available we cannot debug.  */
  if (ps_pglobal_lookup (ps, LIBPTHREAD_SO,
			 "__pthread_threads_events", &addr) != PS_OK)
    return TD_NOLIBTHREAD;

Символ __pthread_threads_events встречается в libpthread.so.0 только в
отладочной информации - он не экспортируется (и правильно - программам,
кроме отладчика, нечего делать в этих внутренностях). Есть еще несколько
аналогичных символов. Поэтому после отрезания отладочной информации
libthread_db.so.1 просто не видит потоков.

В сборке glibc-2.2.5-alt12 (Master updates) /lib/libpthread.so.0
содержит отладочную информацию, поэтому там эта проблема не возникает
(если только не добавить к нему glibc-core-i686 из Сизифа - там
/lib/i686/libpthread.so.0 обрезанный).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

On Tue, Sep 24, 2002 at 06:00:41PM +0400, Sergey Vlasov wrote:
> > > > Workaround:
> > > > 1. установить пакет glibc-core-debug и
> > > > 2. запускать gdb/ddd с LD_LIBRARY_PATH=/usr/lib/debug
> > > 
> > > _ОГРОМНОЕ_ спасибо! это действительно помогло (осталось только подумать как
> > > это пристроить удобнее - но это уже детали)
> > 
> > Честно говоря, мне пока что не ясно, почему эту нужно делать для
> > многопоточных программ (для обычных - не нужно).
> > Возможно, в по'strip'анном libpthread удалена какая-то важная для gdb
> > информация. Если кто-нибудь в курсе, напишите.
> 
> Я, кажется, понял, в чем дело. В gdb поддержка потоков теперь сделана
> через libthread_db.so.1 (linuxthreads_db в glibc), а там в коде можно
> обнаружить, например, следующее:
> 
>   /* Get the global event mask.  This is one of the variables which
>      are new in the thread library to enable debugging.  If it is
>      not available we cannot debug.  */
>   if (ps_pglobal_lookup (ps, LIBPTHREAD_SO,
> 			 "__pthread_threads_events", &addr) != PS_OK)
>     return TD_NOLIBTHREAD;
> 
> Символ __pthread_threads_events встречается в libpthread.so.0 только в
> отладочной информации - он не экспортируется (и правильно - программам,
> кроме отладчика, нечего делать в этих внутренностях). Есть еще несколько
> аналогичных символов. Поэтому после отрезания отладочной информации
> libthread_db.so.1 просто не видит потоков.
> 
> В сборке glibc-2.2.5-alt12 (Master updates) /lib/libpthread.so.0
> содержит отладочную информацию, поэтому там эта проблема не возникает
> (если только не добавить к нему glibc-core-i686 из Сизифа - там
> /lib/i686/libpthread.so.0 обрезанный).

Ok, будем документировать это как feature?
Или следует что-то сделать с /lib/libpthread.so.0?


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

On Tue, 24 Sep 2002 18:17:42 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> On Tue, Sep 24, 2002 at 06:00:41PM +0400, Sergey Vlasov wrote:
> > Я, кажется, понял, в чем дело. В gdb поддержка потоков теперь сделана
> > через libthread_db.so.1 (linuxthreads_db в glibc), а там в коде можно
> > обнаружить, например, следующее:
> > 
> >   /* Get the global event mask.  This is one of the variables which
> >      are new in the thread library to enable debugging.  If it is
> >      not available we cannot debug.  */
> >   if (ps_pglobal_lookup (ps, LIBPTHREAD_SO,
> > 			 "__pthread_threads_events", &addr) != PS_OK)
> >     return TD_NOLIBTHREAD;
> > 
> > Символ __pthread_threads_events встречается в libpthread.so.0 только в
> > отладочной информации - он не экспортируется (и правильно - программам,
> > кроме отладчика, нечего делать в этих внутренностях). Есть еще несколько
> > аналогичных символов. Поэтому после отрезания отладочной информации
> > libthread_db.so.1 просто не видит потоков.
> > 
> > В сборке glibc-2.2.5-alt12 (Master updates) /lib/libpthread.so.0
> > содержит отладочную информацию, поэтому там эта проблема не возникает
> > (если только не добавить к нему glibc-core-i686 из Сизифа - там
> > /lib/i686/libpthread.so.0 обрезанный).
> 
> Ok, будем документировать это как feature?
> Или следует что-то сделать с /lib/libpthread.so.0?

А что с ним можно сделать? Разве что не делать strip. Экспортировать так
просто не получится - pthread_keys вообще static, да и имя неподходящее,
корежить внутренности glibc лишний раз... бррр... Кстати, в glibc-2.3
все так же?

Но сделать что-то надо - иначе, например, нельзя будет отловить ошибки,
проявляющиеся только с /lib/i686/libpthread.so.0 (и там тоже надо
отключить strip).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] C++ & gdb

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Tue, Sep 24, 2002 at 07:32:27PM +0400, Sergey Vlasov wrote:
> > Ok, будем документировать это как feature?
> > Или следует что-то сделать с /lib/libpthread.so.0?
> 
> А что с ним можно сделать? Разве что не делать strip. Экспортировать так
> просто не получится - pthread_keys вообще static, да и имя неподходящее,
> корежить внутренности glibc лишний раз... бррр... Кстати, в glibc-2.3
> все так же?

Насколько я понимаю, практически без изменений.

> Но сделать что-то надо - иначе, например, нельзя будет отловить ошибки,
> проявляющиеся только с /lib/i686/libpthread.so.0 (и там тоже надо
> отключить strip).

Какие будут варианты?


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]