Re: Filter design for nsmux

[Sergiu Ivanov]

Hello,

On Fri, May 15, 2009 at 8:35 PM,  <olafBuddenhagen@gmx.net> 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