Function keeps getting embedded into object!

[pcmattman]

I've hit a problem in my multitasker. The code compiles fine, but in the process of compiling about 3 references to '_memcpy' are added. This would normally be fine, but there's a problem with this: at the moment I'm using C++, which sort of makes life difficult - no name mangling = serious problem!

The code has no reference to memcpy (apart from a header, where it's defined once as a prototype). I'm stumped on this problem... any ideas?

Edit: example of the error:

Code: Select all

mt.o(.text+0xaa):mtask.cc: undefined reference to `_memcpy'
mt.o(.text+0x15e):mtask.cc: undefined reference to `_memcpy'
mt.o(.text+0x18d):mtask.cc: undefined reference to `_memcpy'

Edit 2: Ahhh, it was in this:

Code: Select all

current_task[0] = ptable[pid];

I didn't realize that was memcpy...

[grimpy]

Edit 2: Ahhh, it was in this:

Code: Select all

current_task[0] = ptable[pid];

I didn't realize that was memcpy...

Seriously, you need to compile your kernel in nostdlib / freestanding mode, so it doesn't emit library calls.

[pcmattman]

I do.

The only other problem with this is that for some really strange reason G++ compiles the whole file as a C file. Even when i explicity tell it to use C++, it still uses C (see the _memcpy example in previous post, and I don't need to use 'extern "C"' on symbols in the file). This makes coding really difficult - any ideas?

[frank]

memcpy is a part of the standard C library right? Doesn't that mean that it will always be declared extern "C". That would explain the name mangling that you are getting.

[pcmattman]

Good point.

Still, the whole file is being treated as a c file, not a c++ file.

[frank]

Are you sure, how can you tell? Not that I don't believe you but some symptoms might help in diagnosing the problem.

[pcmattman]

For a start, I have a structure that is to be accessed from assembly code. It's not defined as extern "C" (I forgot at the time) but there are no problems accessing it as a typical C name, ie. no mangling.

objdump shows this:

Code: Select all

<_ptable>

That's in the BSS section too, when it's defined as a static array?

[frank]

For a start, I have a structure that is to be accessed from assembly code. It's not defined as extern "C" (I forgot at the time) but there are no problems accessing it as a typical C name, ie. no mangling.

Okay well I can't explain that other than to say to look for an unended extern "C" { in some header file somewhere

objdump shows this:

Code: Select all

<_ptable>

That's in the BSS section too, when it's defined as a static array?

It could be in the BSS section if it was either initialized with all zeros or not initialized at all. (IIRC)

[pcmattman]

ptable is defined as

Code: Select all

struct tagTask ptable[1024];

And I don't have an extern "C" in a header...

[frank]

wow thats weird, i don't know what to say about that. Maybe try reinstalling gcc and g++.

[Combuster]

For starters, build a GCC Cross-Compiler instead of using your system gcc.

[pcmattman]

I found the source of the problem: large structures...

And when I tried to build a cross-compiler it didn't work (followed the instructions in the wiki for Cygwin)...

[Solar]

The memcpy() you are seeing is likely not the one from the standard library, but the one built into GCC because the compiler has to copy memory areas itself (like in the case of the object copy you mentioned). It is thus a dependency of the compiler, not of your code.

And when I tried to build a cross-compiler it didn't work (followed the instructions in the wiki for Cygwin)...

"It didn't work" is not a description that could lead to a solution. And while I do offer you to help you with your problem via PM, I would take bets that the instructions are correct (because I have been through this numerous times).

[pcmattman]

"It didn't work" means it didn't work and I don't want to resolve it yet.

Basically, the cross-compiler didn't compile. It spewed errors about multiply defined symbols and such... I'm about to try again and if it doesn't work I'll post here, if it'll make you happy

Edit: here's the problem:

Code: Select all

make[4]: Entering directory `/usr/src/build-binutils/binutils'
/bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototy
pes -Werror -g -O2   -o ar.exe  arparse.o arlex.o ar.o not-ranlib.o arsup.o rena
me.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../
libiberty/libiberty.a
gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -o ar.exe a
rparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o buc
omm.o version.o filemode.o  ../bfd/.libs/libbfd.a ../libiberty/libiberty.a
arlex.o: In function `main':
/usr/src/build-binutils/binutils/arlex.c:1: multiple definition of `_main'
arparse.o:/usr/src/build-binutils/binutils/arparse.c:1: first defined here
ar.o: In function `main':
/usr/src/build-binutils/binutils/../../binutils-20060817-1/binutils/ar.c:337: mu
ltiple definition of `_main'
arparse.o:/usr/src/build-binutils/binutils/arparse.c:1: first defined here
ar.o: In function `mri_emul':
/usr/src/build-binutils/binutils/../../binutils-20060817-1/binutils/ar.c:141: un
defined reference to `_yyparse'
collect2: ld returned 1 exit status

[Brynet-Inc]

You could always try using Google or something, I'm going to make an educated guess and say you're missing "bison"

Hope that helps...