I have userland from the i386 ELF snapshot, just with newer gcc and
gdb - I recompiled them about a month ago to correct the problem
with bad line numbers. Both gdb & gcc are build agains "old" libc.so.12.44.
Kernel is the very current, say day or so old, though I doubt it's
significant.

I have problem tracing functions inside shared libraries, such as:

(gdb) break main
Breakpoint 1 at 0x804877f: file ctype-latin2.c, line 87.
(gdb) run
Starting program: /usr/src/lib/libc/locale/cs/il2 

Breakpoint 1, main () at ctype-latin2.c:87
87              __savectype("ff", ctype_latin2, to_upper_latin2, to_lower_latin2);
(gdb) s
__savectype (name=0x8048887 "ff", new_ctype=0x80498e0 "", 
    new_toupper=0x8049be2, new_tolower=0x80499e2)
    at /usr/src/lib/libc/locale/ctypeio.c:131
131             u_int32_t i, len = _CTYPE_NUM_CHARS;
(gdb) n
133             if ((fp = fopen(name, "w")) == NULL)
(gdb) n
0x4806c454 in _init ()
(gdb) n
Single stepping until exit from function _init, 
which has no line number information.

Program exited normally.
(gdb) quit

Note: __savectype() is function in libc. I can step into it without
problems. Then, gdb get's confused by the call to the next function
located in the same shared library (i.e. fopen()). I see
the same problem when tracing some other program - I can step into setlocale()
without problems, but gdb get's confused when setlocale() calls
getenv().

The libc is almost-current libc (i.e. 12.45, supped tonigh) I've just build.

Anyone seen something similar ? Or is it corrected already and I should
upgrade my build tools ? Can it be something with weak aliases or something
like that ?

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
"The only way how to get rid temptation is to yield to it." -- Oscar Wilde