我曾做过一个牢固的C发展轨道,但总是来自供应商内部的 garden园。 由于这是一次毫不含糊的可怕经验,因为我最近提出的一个项目是让海合会、开放式海委会、非洲开发银行和埃恩茨在我通常的含水层环境中玩.。 我已经对项目进行了测试,并做了很好的工作,但我对无法查获的Im链接错误进行了研究,我想知道,除了具体错误外,这几类事情还有debuggingmeth。
我的实际问题: 我有一个通过其“发射台”的跳板“TI tm4c123”。 I m 编辑从32个轨道档案。 缩略语 没有任何问题;它完全是汇编、闪电和清醒。 直到我需要<代码>。 然后,从研究无数其他问题来看,“未明确提及......sbrk:”似乎与在提供<条码>libc所用扫描定义的图书馆之间没有联系。 罚款。 通过链式图书馆搜索途径,我发现libnosys.a,但与这一条相联系似乎只是将问题推向一步,并产生了“未明确提及” 此时此刻,我担心
While I d welcome a quick resolution to my particular problem ("add option foo to compile step bar" or something), I d actually prefer if, in addition, anyone could point me to resources that would help me understand how MCUs, embedded ABIs, linkers, and libraries all interact―what, exactly, are the assumptions that the arm-none-eabi-gcc toolchain is making about the execution environment and the code that ll eventually get linked in? How does one modify or satisfy those assumptions, in order to actually get an .elf that flashes and runs correctly on an MCU? There seem to be a great many questions related to similarly-named errors, and they range over a large variety of actual underlying bugs. Understanding exactly what the tools are doing and why would help greatly in sorting out the differences.
Here s a minimum non-working example, for discussion:
// ./main.c
#include <stdlib.h>
#include <stdint.h>
int main() {
uint8_t *ptr = malloc(3);
ptr[0] = 0xb0;
ptr[1] = 0x0b;
}
# ./Makefile
CC = arm-none-eabi-gcc
LD = arm-none-eabi-ld
CFLAGS = -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -ffunction-sections
-fdata-sections -MD -std=c2x -Wall -Wextra -Werror -DPART_${MCU} -c -O0 -Dgcc -ggdb
LIBGCC := ${shell ${CC} ${CFLAGS} -print-libgcc-file-name}
LIBC := ${shell ${CC} ${CFLAGS} -print-file-name=libc.a}
LIBM := ${shell ${CC} ${CFLAGS} -print-file-name=libm.a}
LIBSTUB := ${shell ${CC} ${CFLAGS} -print-file-name=libnosys.a}
LDFLAGS = -T linkerscript.ld -e Reset_Handler --gc-sections ${LIBM} ${LIBGCC} ${LIBC} ${LIBSTUB}
all: mwe.elf
startup.o: startup.c
$(CC) -o $@ $^ $(CFLAGS)
main.o: main.c
$(CC) -o $@ $^ $(CFLAGS)
mwe.elf: main.o startup.o
$(LD) -o $@ $^ $(LDFLAGS)
.PHONY: all
Include also the ./startup.h, ./startup.c, and ./linkerscript.ld files from the project guide linked above; I omitted them for brevity. Putting all mentioned files in a single directory and running make (with an ARM gcc toolchain installed: arm-none-eabi-gcc, arm-none-eabi-newlib, and arm-none-eabi-binutils for me on Arch) has reproduced the exact error, along with some extra warnings.