3

I'm working on some software which for a limited time runs bare-metal until the Linux port is ready for prime time. The software is being linked against uClibc which provides implementations of malloc, clock_gettime etc, but the problem is that they all rely on syscalls which will just trap the hardware since we don't have a kernel to handle them yet.

I have been using aliasing to override the functions that we need, i.e. our_mem.c:

void* our_malloc(size_t size) { .. }
void* malloc(size_t size) __attribute__ ((malloc, weak, alias("our_malloc")));

The problem is that this seems to work somewhat randomly. I can have one build where all the calls are aliased properly, in the next build where I modified something in an unrelated file it suddenly works up until a point and then one of the calls go to uClibc malloc instead. At first I thought it was a matter of link order but the build system always links in the same order and the same call will work in one build and fail in the next. The binaries are (obviously) statically linked.

I'm not sure this is exactly how aliasing is meant to be used since I haven't found much documentation on it but I have successfully used this technique a few years before on malloc and friends (also with uClibc) and then it worked consistently.

Zoe
  • 27,060
  • 21
  • 118
  • 148
David Holm
  • 17,522
  • 8
  • 47
  • 47
  • Hard to tell without knowing the system at all, but could it have something to do with build order when some files are already up to date from the last build? Does a `make distclean all` have consistent behaviour? Other option I can think of is partial linking (-Ur/-r) messing up, I've had some trouble with that (which may have been due to me misunderstanding how to build a makefile for it). – Joachim Isaksson Aug 16 '13 at 16:51
  • We are not using partial linking. I haven't tried comparing two clean builds side by side yet but I will as soon as I have some spare time. – David Holm Aug 16 '13 at 18:16

0 Answers0