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]

Re: debugging - my own libc

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.

[Eric Sosman]

Re: debugging - my own libc

S James S Stapleton wrote:

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?

Not in portable C: All the Standard says is that if you use one
of the library's identifiers, the effect is undefined. (Pedant alert:
Yes, I've over-stated the case. Let it go.)

That said, many systems have system-specific ways to do such
things. On some you can just write your own strtok() or whatever
and link it into your program and all will be well -- except that
you can no longer use the "real" strtok() at all, not even as the
underpinnings of your replacement. On other systems you may be
able to "interpose" your own code between the caller and the
library function, so that your strtok() can do some special magic
and then hand the call off to the real strtok(). Still other
systems may have still other ways to do things.

You don't say what you want to do with these modified library
functions, but I'm guessing you want to sanity-check the arguments
or perhaps log them somewhere. Many systems provide (system-
specific) tools to do this sort of thing without changing the code:
debuggers, tracing tools, and the like. If your system has such tools
and if they meet your needs, I think you'll be better off using them
than trying to muck around with the library.

--
Eric.Sosman@sun .com

[Ben Bacarisse]

Re: debugging - my own libc

"S James S Stapleton" <stapleton.41@o su.eduwrites:

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.

--
Ben.

[Flash Gordon]

Re: debugging - my own libc

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.
--
Flash Gordon

[CBFalconer]

Re: debugging - my own libc

S James S Stapleton wrote:

>
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.



--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[S James S Stapleton]

Re: debugging - my own libc


"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:hmien5x1kv .ln2@news.flash-gordon.me.uk...

>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]

Re: debugging - my own libc

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

"Flash Gordon" <spam@flash-gordon.me.ukwro te in message
news:hmien5x1kv .ln2@news.flash-gordon.me.uk...

>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
>implementation s.

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

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

>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...

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.progr ammer
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).

>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.

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.
--
Flash Gordon