On Fri, Mar 10, 2000 at 06:51:20PM -0500, Chuck Robey wrote:
> I wasn't reading this too closely, but if you're trying to hand feed in
> the object files, the C startup object file *MUST* come first in the list
> of object files, because it's gotta link at the lowest address ...
>
> Is that it?
Ok, I'm even more puzzled than before...
If I link them in this order: nss-test.o crt1.o crti.o
I get the following:
files called
files called
retval = 1
NS_SUCCESS
Bus error (core dumped)
Notice the duplicate line that says "files called"? This had me puzzled
before, but now I see that somehow _init point to the first function
in the first object file
(gdb) p _init
$1 = {<text variable, no debug info>} 0x8048074 <files>
Now if I like it in this order: crt1.o crti.o nss-test.o
I get an infinite recursion!!!!
(gdb) p _init
$1 = {<text variable, no debug info>} 0x8048074 <_start>
since _start calls _init() *before* calling main() it just loops
(and starts swapping like hell)
Let me try this order: crti.o crt1.o nss-test.o
(gdb) p _init
$1 = {<text variable, no debug info>} 0x8048074 <_start>
nope, same as before. infinite recursion and swapping like hell.
maybe this order: crt1.o nss-test.o crti.o
(gdb) print _init
$1 = {<text variable, no debug info>} 0x8048074 <_start>
same thing.
I created a small C file:
#include <stdio.h>
foo() {
printf("foo\n");
}
and tried this order: foo.o nss-test.o crt1.o crti.o
(gdb) print _init
$1 = {<text variable, no debug info>} 0x8048074 <foo>
and if I just run it...
foo
files called
retval = 1
NS_SUCCESS
Bus error (core dumped)
If I try gdb with a normal program (i.e. one linked with the standard
C library in /usr/lib and not my own C library)
(gdb) print _init
$1 = {<text variable, no debug info>} 0x804838c <_init>
What could be the problem?
regards,
-oscar
--
pgp public key: finger [EMAIL PROTECTED]
pgp fingerprint: 6D 18 8C 90 4C DF F0 4B DF 35 1F 69 A1 33 C7 BC
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
