Proxmark3 community

holiman

Contributor

Registered: 2013-05-03

Posts: 566

Proxmark build system (makefiles)

When making some changes to the mifare classic hack on the device, I found a need to use rand() from stdlib. Compiling works fine, but linking not so fine:

martin@lenovox2:~/workspace/proxmark3-scripting/armsrc
$ make
perl ../tools/mkversion.pl .. > version.c || cp ../common/default_version.c version.c 
arm-none-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=c99 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO14443a -DWITH_ISO14443b -DWITH_ICLASS -DWITH_LEGICRF -DWITH_HITAG -I. -Os -mthumb -mthumb-interwork -o obj/version.o version.c 
arm-none-eabi-gcc -nostartfiles -nodefaultlibs -Wl,-gc-sections -n -Wl,-T,ldscript,-Map,obj/fullimage.map -o obj/fullimage.elf obj/version.o obj/fpga.o obj/start.o obj/iso15693.o obj/iso15693tools.o obj/lfops.o obj/hitag2.o obj/appmain.o obj/printf.o obj/util.o obj/string.o obj/usb_cdc.o obj/cmd.o obj/fpgaloader.o obj/legicrf.o obj/iso14443crc.o obj/crc16.o obj/epa.o obj/iso14443a.o obj/mifareutil.o obj/mifarecmd.o obj/mifaresniff.o obj/iso14443.o obj/crapto1.o obj/crypto1.o obj/legic_prng.o obj/iclass.o obj/crc.o -lgcc
obj/iso14443a.o: In function `ReaderMifare':
iso14443a.c:(.text+0x1d68): undefined reference to `rand'
collect2: error: ld returned 1 exit status
make: *** [obj/fullimage.elf] Error 1

If I remove the switch '-nodefaultlibs', it works fine:

$ arm-none-eabi-gcc -nostartfiles -Wl,-gc-sections -n -Wl,-T,ldscript,-Map,obj/fullimage.map -o obj/fullimage.elf obj/version.o obj/fpga.o obj/start.o obj/iso15693.o obj/iso15693tools.o obj/lfops.o obj/hitag2.o obj/appmain.o obj/printf.o obj/util.o obj/string.o obj/usb_cdc.o obj/cmd.o obj/fpgaloader.o obj/legicrf.o obj/iso14443crc.o obj/crc16.o obj/epa.o obj/iso14443a.o obj/mifareutil.o obj/mifarecmd.o obj/mifaresniff.o obj/iso14443.o obj/crapto1.o obj/crypto1.o obj/legic_prng.o obj/iclass.o obj/crc.o -lgcc

Obviously, someone put that switch there for a reason, and I don't want to change something when I don't know what the consequences are. The makefile-system is pretty complicated, at least to me since I am a no expert on makefiles. The switch gets included from common/makefile.common. Is it possible to use stdlib-functions on the ARM? How should I enable proper linking of that during make?

yonkers

Member

Registered: 2013-07-03

Posts: 9

Re: Proxmark build system (makefiles)

I wondered about that too, seeing that someone chose -nostdlibs and then included the relevant parts in e.g. string.c (which reimplements some C library functionality). Also the CRT code is written manually. Maybe there was, at the time of writing, some incompatibility between the newlib CRT code, which forced the author to use -nostartfiles. Or, maybe more likely, the author didn't want people to need to compile newlib. In any case, if linking against newlib would be done properly you'd end up with a cleaner codebase (no code duplication, use of standard functionality) and also have the benefit of having *all* C functions available instead of just the duplicated subset.

Have you tried it out? What were the results? Sould I give it a shot? I've ported some manual startup code to newlib before, albeit for a ARM Cortex M4 (but there's not relaly a world of difference between the M4 and the 7TDMI).

piwi

Contributor

Registered: 2013-06-04

Posts: 704

Re: Proxmark build system (makefiles)

Maybe size matters? By reimplementing standard functions you could get rid of unnecessary overhead. Did you compare the code size with standard lib and reimplemented functions?

holiman

Contributor

Registered: 2013-05-03

Posts: 566

Re: Proxmark build system (makefiles)

I didn't experiment further  - I only needed a random-ish function to fetch numbers from, and I found another thing I could use instead. From the code (iso1443a.c):

        //[Martin:]I would like to have used rand(), but linking problems prevented it
2021	        //offset_time = rand() % 4000;
2022	        //So instead, I found this nifty thingy, which seems to fit the bill
2023	        offset_time = GetTickCount() % 2000;

I have absolutely zero experience with ARM-development... I like the idea of being able to use standard c, but as of right now that's not a concern for me. If anyone wants to change the way it is, I'm all for it, but don't think I have much to contribute in this area..

yonkers

Member

Registered: 2013-07-03

Posts: 9

Re: Proxmark build system (makefiles)

I doubt size is the issue. The standard libraries are compiled together in an .a file in which every single function has its own object file. This means that automatically *only* the code for the functions is pulled in that is actually used. I highly doubt that you can get smaller by manually doing this. Embedded standard libraries (like newlib) are already implemented to have a low ROM footprint.

yonkers

Member

Registered: 2013-07-03

Posts: 9

Re: Proxmark build system (makefiles)

I've looked into this. The reason seems to be that the original author wanted the library functions to be available in Thumb format, not in ARM code. Trampolines are automatically created to make Thumb calls from ARM. By default the C standard library is wired the other way around: It consists of ARM code with Trampolines for calling it from Thumb. In general, Thumb code is more dense but slower than ARM. Therefore, there is indeed a code size increase (about 2 kB) when using the standard library.