1. Home
  2. Embedded Programming
  3. undefined reference to sbrk

undefined reference to sbrk

I have tried to sort out the "unbdefined reference sbrk" message. First my system comfiguration, then my attempts. I have to build an executable (elf file) for powerpc with gnu-gcc 4.2.2. installed on windows XP. The tool chain works properly because I already managed to build several other projects without using function with dynamic allocation (e.g., malloc). The options that I use for compilaing: -gdwarf-2 -c -fno-exceptions -finline linking: -nostartfiles -v -Xlinker --output=$(OUTPUTFILE) -Xlinker

-Map=map.txt -Xlinker --script=$(INDPATH) -lc -lm (INDPATH points to my linker script file).

To sort the problem, I have written my bsrk implementaion in a file, systemcall.c that is part of my project. Then, I modified also the script file to add the heap section.

I build the project with the former link option and I still get the same error.

I build with -nostartfiles -v -Xlinker --output=$(OUTPUTFILE) -Xlinker

-Map=map.txt -Xlinker --script=$(INDPATH) -o systemcall.o -lc -lm , error again

I build with -nostartfiles -v -Xlinker --output=$(OUTPUTFILE) -Xlinker

-Map=map.txt -Xlinker --script=$(INDPATH) -lc -lm -lyk -> NO ERROR, but when I run the program it gets stuck after I call the malloc function. I tried to find out on -lyk, but I haven't found satisfing info. I suspect that option provides a stub to the compiler with the _bsrk symbol, thus the compiler doesn't complain, but an actual implementation is missing.

How can I sort this problem? Another attemp that I was thinking of doing is to create from systemcall.o a static library and force the linker to link it wit -l option (or -L if I do not place the library in the "sys" folder). Any help is appreciated, thank you.

--------------------------------------- Posted through

formatting link

Reply to
puntino
Loading thread data ...

If you have source for the library you can grep for sbrk, to get an idea of who calls it -- then either don't use that part of the library, or make your own (possibly dummy) sbrk function.

--
www.wescottdesign.com
Reply to
Tim Wescott

Or, add a dummy sbrk() function, build the program, and look at the code to see who's calling it.

I just did that a few days ago. Turned out the culprit was the atof() function in newlib, which in turn called strtod, which called Balloc(). It's annoying that dynamic memory is required for a simple routine like that, but I was lucky that I could work around the atof() call.

Reply to
Arlet Ottens

-----------------------------------------------------^^^^

-----------------------------------------^^^^

Is this a typographical error? (sbrk vs bsrk)

-------------------------------------------------------_^^^^

At the top of the post, you said the *linker* was throwing an "undefined reference" error. So, whatever is *referencing* "sbrk" (at least, I *think* that's what your symbol is called) is doing so via external linkage (i.e., the compiler won't catch the undefined reference but the linkage editor will)

*If* you are trying to resolve the undefined reference (i.e., to get the link to complete), you should be able to grep(1) all the sources and headers in your project to see where it is referenced.

If you have some objects/libraries without sources, you should be able to examine their symbol tables for "U" references to sbrk.

Finally, if you just want to get *to* the reference(s) (so you know where to look), link in a dummy sbrk.c so you have deliberately defined the label in question. Verify that the "unresolved" goes away.

Compile without optimization but with debug info.

Link.

Load the executable and set a breakpoint at "sbrk".

Run.

Look at a back trace to see where the call *to* sbrk originated (my bet: check crt0.s).

Lather, rinse, repeat.

Reply to
Don Y

sbrk is called when malloc() initializes, which is usuallly the first time you call it. It is responsible establishing the end of the heap, usually at a symbol named _end.

The problem is usually called by a linker config issue not setting up the heap correctly. From my experience you would be better off choosing a new compiler than trying to solve this. But if you do come to a good solution, please post it here.

--
Scott
Validated Software
Lafayette, CO 



__________ Information from ESET NOD32 Antivirus, version of virus signature
database 6332 (20110728) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
Reply to
Not Really Me

It is standard to have to implement one's own sbrk routine when using newlib's dynamic memory functions. There are examples for a simple implementation in newlib's documentation. Some newlib's are compiled with just a stub so that one does not get linker errors, but malloc etc. does not work. One can either make sure that one's own routine is linked first, or remove the dummy sbrk routine from the newlib library and link with one's own. The "dummy" or stub sbrk routine is also sometimes implemented to do a syscall. One then has to supply the correct syscall. On ARM this is typically done so that one's own code is run in user mode, while the heap management routines can run in system mode. Search for "Porting newlib" to find information regarding this issue.

Regards Anton Erasmus

Reply to
Anton Erasmus

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.