Hello, On Fri, May 15, 2009 at 8:35 PM, <[email protected]> wrote: > On Mon, May 11, 2009 at 10:18:59PM +0300, Sergiu Ivanov wrote: > >> antrik told me to try to step into the dir_lookup call, but gdb does >> not want to comply with my desires... I installed hurd-dbg package (as >> antrik had recommended), but it didn't help. > > Eh, right... You obviously need libc0.3-dbg for that rather than > hurd-dbg -- glibc is where most of the client side stuff resides. Sorry. > > However, using libc-dbg is tricky: The symbols are not loaded > automatically, unlike with other -dbg packages. IIRC you have to set > LD_LIBRARY_PATH to /lib/debug/lib or something... Except that it doesn't > seem to work anymore :-( So I can't really help here. > > Also note that for single-stepping, you need to get the source code as > well, and point gdb to the right location. (I used a trick in the past: > Create a symlink to make the source code appear at the same location as > it was on the build host, so gdb picks it up automatically...)
I see... I'll try this anyway, in the hope that I might manage to load the debug symbols somehow... >> However, everything looks to be very much like our supposition: >> dir_lookup does not even try to invoke the corresponding RPC and >> decides what to do on its own. > > Again, guessing is not helpful. Single-stepping would be nice, but it > you can't do that, you can at least look up the code of the dir_lookup() > stub in the glibc tree, and try to understand what is actually going > on... I'll look there right now. Actually, this is what I am doing now: apt-getting source glibc. > (Note that the stubs are generated files, i.e. you have to build glibc > to look at them.) Thanks a lot! I would have wondered where are the stubs, hadn't you told me this... Regards, scolobb
