On Tue, 2003-08-05 at 01:46, Antonio Castro wrote:
> On 4 Aug 2003, Cesar Rincon wrote:
> > Nunca he usado DDD pero, como ya te dec�a hace unos d�as, en GDB el
> > comando 'step' debe funcionar *siempre* como indicas: entrando en las
> > subrutinas (excepto cuando la subrutina est� en una biblioteca enlazada
> > sin informaci�n de debug). El comando 'next' es el que salta las
> > subrutinas.
>
> A mi me parece que eso no es cierto. Todos los debugger son susceptibles
> de perderse. Yo creo que un puntero descontrolado puede llegar a afectar
> al correcto funcionamiento del debugger. No es algo corriente per puede
> llegar a pasar.
Es algo poco corriente, en efecto: t�nto que no recuerdo que me haya
pasado con GDB, excepto cuando se genera un SIGSEGV o SIGBUS en
programas con threads o que hacen fork(). En cualquier caso, yo creo
que un debugger tiene mejores posibilidades que tu sistema de "trazas"
de sobrevivir una implosi�n del programa causada por un apuntador
corrupto.
Muy bonito e ingenioso, tu c�digo, de cualquier forma. Mucho m�s fino
que mis habituales printf()s :-) Es poco portable, sin embargo: los
macros vari�dicos son una adici�n de C99, y el est�ndar manda el uso de
la construcci�n __VA_ARGS__ (no tengo una copia de C99 ahora mismo, pero
estoy casi seguro de que 'args...' es una extensi�n de GNU---ve la
secci�n de macros vari�dicos en el manual de CPP). En el mismo tenor,
__FUNCTION__ es una extensi�n de GNU, no una construcci�n est�ndar (a
diferencia de __FILE__ y __LINE__).
Un truco que he usado para evitar los macros vari�dicos, y a�n as� tener
sem�ntica de printf() y desactivaci�n del c�digo de log redefiniendo
macros, es el siguiente:
void funcion_de_log(const char* formato, ...);
#define MI_LOG(_nivel_de_log, _params)\
do {\
if(_nivel_de_log <= nivel_global_de_log) funcion_de_log _params ;\
} while(0)
Eso se usa as�:
MI_LOG(LOG_DEBUG, ("Error %d", e));
No recuerdo d�nde me aprend� ese truco. Creo que la NSPR lo usa en su
implementaci�n de logs. Como sea, quiz� podr�a adaptarse para la
implementaci�n de "trazas" como la que presentas de una manera mas
portable.
Para regresar al tema, se me ocurri� una idea que puede explicar lo que
est� pasando a Gustavo. Si esta depurando contenedores STL, podr�a ser
que GCC los est� expandiendo inline, de forma que no hay manera de "no
entrar" en los "m�todos" de sus contenedores. �Alguien tiene
experiencia depurando templates de C++ con GDB?
-CR
