OSDev.org

Posted: **Fri May 04, 2007 4:14 am**

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

Posted: **Fri May 04, 2007 9:54 am**

pcmattman wrote: 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.

Posted: **Fri May 04, 2007 4:57 pm**

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?

Posted: **Fri May 04, 2007 6:29 pm**

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.

Posted: **Fri May 04, 2007 6:31 pm**

Good point.

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

Posted: **Fri May 04, 2007 6:33 pm**

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

Posted: **Fri May 04, 2007 6:41 pm**

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?

Posted: **Fri May 04, 2007 6:49 pm**

pcmattman wrote: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

pcmattman wrote: 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)

Posted: **Fri May 04, 2007 6:56 pm**

ptable is defined as

Code: Select all

struct tagTask ptable[1024];

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

Posted: **Fri May 04, 2007 7:13 pm**

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

Posted: **Sun May 06, 2007 4:02 am**

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

Posted: **Fri May 18, 2007 5:07 am**

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

Posted: **Fri May 18, 2007 6:50 am**

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.

pcmattman wrote: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).

Posted: **Fri May 18, 2007 4:17 pm**

"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

Posted: **Fri May 18, 2007 9:53 pm**

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

OSDev.org

Function keeps getting embedded into object!

Function keeps getting embedded into object!

Re: Function keeps getting embedded into object!