debugging - my own libc

[S James S Stapleton]

I want to debug a program, but I can't figure out what I'm doing wrong. I am
screwing up a part of my libc (which I have access to the source for).

If I compile my own copy of these functions, is it possible to compile/link
a program against this library and the system's libc, but when both export
the functions, have the functions in my library hold precidence?

Thanks

 

[S James S Stapleton]

Ugh, I typoed that badly. Sorry.

I'm having trouble with part of a program I'm working on - I'm not writing
my own libc. I want to take a copy of some functions in libc, add a bunch of
diagnostic outputs, and see where and why my code is failing.

Sorry, I need to slow down when I type, so what I am trying to say resembles
comprehensible language. I'm sorry for the obnoxious original post.

Thanks.

 

[Ben Bacarisse]

I'm having trouble with part of a program I'm working on - I'm not writing
my own libc. I want to take a copy of some functions in libc, add a bunch of
diagnostic outputs, and see where and why my code is failing.

Often, the simplest way to do this is via some system-specific
extension to rename functions at link time. With gcc, for example,
--wrap strcpy makes the symbol strcpy map to __wrap_strcpy and
__real_strcpy be a reference to the original. You write a library of
wrappers, and by altering the link options you can turn on more or less
debugging.

 

[Flash Gordon]

S James S Stapleton wrote, On 14/08/08 20:51:

Ugh, I typoed that badly. Sorry.

I'm having trouble with part of a program I'm working on - I'm not writing
my own libc. I want to take a copy of some functions in libc, add a bunch of
diagnostic outputs, and see where and why my code is failing.

Some systems provide a mechanism for overriding specific functions, and
sometimes for calling the standard function from within your version,
but others do not. The mechanism for doing so also varies. So for
details on how to do that you will have to ask on a group dedicated to
your implementation.

Other options I can think of include doing things like:
#define malloc(x) mymalloc(x)
I believe this invokes undefined behaviour if you have included the
standard header that declares the function, but it will work on many
implementations.

Installing and using a debug version of the standard library so you can
step in to any functions you want.

One of the most common causes (in my experience) of "failures in libc"
is you overrunning the end of a buffer. For this tools like vagrind can
be very useful. Depending on what debug you want to do then tools like
strace may also be useful if available on your system.

However, for the best advice on what is available for your system you
will have to ask on a group dedicated to your system. For this reason
details of specific tools and systems are generally considered off-topic
here.

Sorry, I need to slow down when I type, so what I am trying to say resembles
comprehensible language. I'm sorry for the obnoxious original post.

Your original post did not seem obnoxious to me, just hard to understand.

 

[CBFalconer]

I want to debug a program, but I can't figure out what I'm doing
wrong. I am screwing up a part of my libc (which I have access to
the source for).

If I compile my own copy of these functions, is it possible to
compile/link a program against this library and the system's libc,
but when both export the functions, have the functions in my
library hold precidence?

I assume you are referring to functions described in the C
standard. (If not there should be no problem.) The presence of
problems depends on your linker, and is really OT here. But you
should often be able to simply link your new modules, holding your
version of those functions, before the actual library. Most C
systems arrange to link the library after the items on the command
line. Since, by this time, your link has found your new modules,
they are no longer undefined and do not need linking in.

If these replaced functions are in a separate library, just ensure
you link your units before that library.

 

[S James S Stapleton]

S James S Stapleton wrote, On 14/08/08 20:51:
Other options I can think of include doing things like:
#define malloc(x) mymalloc(x)
I believe this invokes undefined behaviour if you have included the
standard header that declares the function, but it will work on many
implementations.

Thanks, I should have thought of that, looks simple/straightforward.

One of the most common causes (in my experience) of "failures in libc" is
you overrunning the end of a buffer. For this tools like vagrind can be
very useful. Depending on what debug you want to do then tools like strace
may also be useful if available on your system.

Actually, the issue is I'm trying to load a library, and dlopen returns a
null without setting an error value. I made dozens of other libraries,
testing things, and it works fine. I can use 'nm -D' to get the symbols out
of this library even. But this one library won't load...

Your original post did not seem obnoxious to me, just hard to understand.

To me, that would make it obnoxious. Obnoxious and rude to the other users
on this forum.


Thanks for the help,
-Jim Stapleton

 

[Flash Gordon]

S James S Stapleton wrote, On 15/08/08 14:29:

Thanks, I should have thought of that, looks simple/straightforward.

If it works it is, if it doesn't it isn't ;-)

Actually, the issue is I'm trying to load a library, and dlopen returns a
null without setting an error value. I made dozens of other libraries,
testing things, and it works fine. I can use 'nm -D' to get the symbols out
of this library even. But this one library won't load...

Both of the tools I suggested above could still be of assistance. If, as
seems likely, you are using a Unix-like system comp.unix.programmer
would be a good place to ask since a number of Unix variants have strace
or similar (a Linux group would be a good place to discuss how valgrind
can help).

To me, that would make it obnoxious. Obnoxious and rude to the other users
on this forum.

Having a bad day is not being obnoxious or rude. Deliberately making
your posts hard to understand (or regularly not bothering to make an
effort) would be.