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
