请问CLANG和GCC的LD文件是不是互相兼容的?

从ARM网站下载的CMSIS5.9.0,执行 ld.lld -T gcc_arm.ld ……
结果总是显示:

在这里插入图片描述

但如果我把LD文件里面的__HEAP_SIZE设为0,则能成功连接并生成ELF文件

LD文件是这样的:

/******************************************************************************
 * @file     gcc_arm.ld
 * @brief    GNU Linker Script for Cortex-M based device
 * @version  V2.1.0
 * @date     04. August 2020
 ******************************************************************************/
/*
 * Copyright (c) 2009-2020 Arm Limited. All rights reserved.
 *
 * SPDX-License-Identifier: Apache-2.0
 *
 * Licensed under the Apache License, Version 2.0 (the License); you may
 * not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an AS IS BASIS, WITHOUT
 * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

/*
 *-------- <<< Use Configuration Wizard in Context Menu >>> -------------------
 */

/*---------------------- Flash Configuration ----------------------------------
  <h> Flash Configuration
    <o0> Flash Base Address <0x0-0xFFFFFFFF:8>
    <o1> Flash Size (in Bytes) <0x0-0xFFFFFFFF:8>
  h>
  -----------------------------------------------------------------------------*/
__ROM_BASE = 0x00000000;
__ROM_SIZE = 0x00008000;

/*--------------------- Embedded RAM Configuration ----------------------------
  <h> RAM Configuration
    <o0> RAM Base Address    <0x0-0xFFFFFFFF:8>
    <o1> RAM Size (in Bytes) <0x0-0xFFFFFFFF:8>
  h>
 -----------------------------------------------------------------------------*/
__RAM_BASE = 0x20000000;
__RAM_SIZE = 0x00001000;

/*--------------------- Stack / Heap Configuration ----------------------------
  <h> Stack / Heap Configuration
    <o0> Stack Size (in Bytes) <0x0-0xFFFFFFFF:8>
    <o1> Heap Size (in Bytes) <0x0-0xFFFFFFFF:8>
  h>
  -----------------------------------------------------------------------------*/
__STACK_SIZE = 0x00000400;
__HEAP_SIZE  = 0x00000C00;

/*
 *-------------------- <<< end of configuration section >>> -------------------
 */

MEMORY
{
  FLASH (rx)  : ORIGIN = __ROM_BASE, LENGTH = __ROM_SIZE
  RAM   (rwx) : ORIGIN = __RAM_BASE, LENGTH = __RAM_SIZE
}

/* Linker script to place sections and symbol values. Should be used together
 * with other linker script that defines memory regions FLASH and RAM.
 * It references following symbols, which must be defined in code:
 *   Reset_Handler : Entry of reset handler
 *
 * It defines following symbols, which code can use without definition:
 *   __exidx_start
 *   __exidx_end
 *   __copy_table_start__
 *   __copy_table_end__
 *   __zero_table_start__
 *   __zero_table_end__
 *   __etext
 *   __data_start__
 *   __preinit_array_start
 *   __preinit_array_end
 *   __init_array_start
 *   __init_array_end
 *   __fini_array_start
 *   __fini_array_end
 *   __data_end__
 *   __bss_start__
 *   __bss_end__
 *   __end__
 *   end
 *   __HeapLimit
 *   __StackLimit
 *   __StackTop
 *   __stack
 */
ENTRY(Reset_Handler)

SECTIONS
{
  .text :
  {
    KEEP(*(.vectors))
    *(.text*)

    KEEP(*(.init))
    KEEP(*(.fini))

    /* .ctors */
    *crtbegin.o(.ctors)
    *crtbegin?.o(.ctors)
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
    *(SORT(.ctors.*))
    *(.ctors)

    /* .dtors */
    *crtbegin.o(.dtors)
    *crtbegin?.o(.dtors)
    *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
    *(SORT(.dtors.*))
    *(.dtors)

    *(.rodata*)

    KEEP(*(.eh_frame*))
  } > FLASH

  /*
   * SG veneers:
   * All SG veneers are placed in the special output section .gnu.sgstubs. Its start address
   * must be set, either with the command line option ?-section-start?or in a linker script,
   * to indicate where to place these veneers in memory.
   */
/*
  .gnu.sgstubs :
  {
    . = ALIGN(32);
  } > FLASH
*/
  .ARM.extab :
  {
    *(.ARM.extab* .gnu.linkonce.armextab.*)
  } > FLASH

  __exidx_start = .;
  .ARM.exidx :
  {
    *(.ARM.exidx* .gnu.linkonce.armexidx.*)
  } > FLASH
  __exidx_end = .;

  .copy.table :
  {
    . = ALIGN(4);
    __copy_table_start__ = .;

    LONG (__etext)
    LONG (__data_start__)
    LONG ((__data_end__ - __data_start__) / 4)

    /* Add each additional data section here */
/*
    LONG (__etext2)
    LONG (__data2_start__)
    LONG ((__data2_end__ - __data2_start__) / 4)
*/
    __copy_table_end__ = .;
  } > FLASH

  .zero.table :
  {
    . = ALIGN(4);
    __zero_table_start__ = .;
    /* Add each additional bss section here */
/*
    LONG (__bss2_start__)
    LONG ((__bss2_end__ - __bss2_start__) / 4)
*/
    __zero_table_end__ = .;
  } > FLASH

  /**
   * Location counter can end up 2byte aligned with narrow Thumb code but
   * __etext is assumed by startup code to be the LMA of a section in RAM
   * which must be 4byte aligned 
   */
  __etext = ALIGN (4);

  .data : AT (__etext)
  {
    __data_start__ = .;
    *(vtable)
    *(.data)
    *(.data.*)

    . = ALIGN(4);
    /* preinit data */
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP(*(.preinit_array))
    PROVIDE_HIDDEN (__preinit_array_end = .);

    . = ALIGN(4);
    /* init data */
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP(*(SORT(.init_array.*)))
    KEEP(*(.init_array))
    PROVIDE_HIDDEN (__init_array_end = .);

    . = ALIGN(4);
    /* finit data */
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP(*(SORT(.fini_array.*)))
    KEEP(*(.fini_array))
    PROVIDE_HIDDEN (__fini_array_end = .);

    KEEP(*(.jcr*))
    . = ALIGN(4);
    /* All data end */
    __data_end__ = .;

  } > RAM

  /*
   * Secondary data section, optional
   *
   * Remember to add each additional data section
   * to the .copy.table above to asure proper
   * initialization during startup.
   */
/*
  __etext2 = ALIGN (4);

  .data2 : AT (__etext2)
  {
    . = ALIGN(4);
    __data2_start__ = .;
    *(.data2)
    *(.data2.*)
    . = ALIGN(4);
    __data2_end__ = .;

  } > RAM2
*/

  .bss :
  {
    . = ALIGN(4);
    __bss_start__ = .;
    *(.bss)
    *(.bss.*)
    *(COMMON)
    . = ALIGN(4);
    __bss_end__ = .;
  } > RAM AT > RAM

  /*
   * Secondary bss section, optional
   *
   * Remember to add each additional bss section
   * to the .zero.table above to asure proper
   * initialization during startup.
   */
/*
  .bss2 :
  {
    . = ALIGN(4);
    __bss2_start__ = .;
    *(.bss2)
    *(.bss2.*)
    . = ALIGN(4);
    __bss2_end__ = .;
  } > RAM2 AT > RAM2
*/

  .heap (COPY) :
  {
    . = ALIGN(8);
    __end__ = .;
    PROVIDE(end = .);
    . = . + __HEAP_SIZE;
    . = ALIGN(8);
    __HeapLimit = .;
  } > RAM

  .stack (ORIGIN(RAM) + LENGTH(RAM) - __STACK_SIZE) (COPY) :
  {
    . = ALIGN(8);
    __StackLimit = .;
    . = . + __STACK_SIZE;
    . = ALIGN(8);
    __StackTop = .;
  } > RAM
  PROVIDE(__stack = __StackTop);

  /* Check if data + heap + stack exceeds RAM limit */
  ASSERT(__StackLimit >= __HeapLimit, "region RAM overflowed with stack")
}

不完全兼容,因为链接器不同,GCC中,链接器的名称是 ld,而在CLANG中,链接器的名称是 lld。
将一个GCC的LD文件转换为CLANG的LD文件需要将所有的 ENTRY 和 EXTERN 符号改为 ENTRY(_symbol) 和 EXTERN(_symbol) 的形式。将所有的 PROVIDE 符号改为 GLOBAL 符号,将 GROUP 和 GROUP_END 符号改为 GROUP_START 和 GROUP_END 符号还有,检查所有的 INCLUDE 符号和 ASSERT 符号是否在CLANG的链接器中也被支持。

CLANG和GCC的LD文件不是互相兼容的。

GCC和CLANG都使用GNU链接器(LD),但它们的实现略有不同,因此生成的链接文件可能会有所不同。尽管这些文件都遵循ELF二进制格式标准,但它们的格式和内容可能不同,因此在使用时需要注意。特别是,如果将使用不同的编译器生成的对象文件混合在一起链接,可能会出现问题。

如果您需要将使用不同编译器生成的对象文件链接在一起,建议使用通用的中间表示形式,例如LLVM字节码或汇编代码,以确保兼容性。或者,您可以使用同一编译器的不同版本,以确保使用相同的链接器实现。

以下答案由GPT-3.5大模型与博主波罗歌共同编写:
Clang 和 GCC 的 LD 文件基本上是互相兼容的,但是,不同的工具链可能对同一段代码的处理方式和调整有所不同。因此,在使用不同的工具链生成代码或库时,建议仔细检查编译器和连接器选项,确保生成的目标文件或库是相同的。

从你提供的代码和错误信息来看,可能是由于 LD 文件中的堆栈配置不正确导致连接错误。当堆大小为零时,连接符合预期。建议检查堆大小是否合适,并确保连接器选项正确。如果无法解决问题,请提供更多错误信息和完整的编译和连接器命令行以便更好的帮助。

以下是一些可能有用的链接器选项:

  • -Map : 生成链接器映射文件。
  • -Wl,--print-memory-usage: 输出内存使用报告。
  • -Wl,-Map,: 生成链接器映射文件。
  • -Wl,-T : 使用特定的链接器脚本文件。
  • -Wl,--gc-sections: 删除未使用的 section,以减小目标文件的大小。
    如果我的回答解决了您的问题,请采纳!
该回答引用于gpt与OKX安生共同编写:
  • 该回答引用于gpt与OKX安生共同编写:
  • CLANG和GCC的LD文件通常是兼容的,因为它们都遵循相同的ELF格式(Executable and Linkable Format)。但是,这并不意味着你可以在使用GCC编译的程序中直接使用CLANG编译器生成的目标文件。因为不同编译器可能使用不同的命令行选项、ABI(Application Binary Interface)等功能,这可能会导致二进制文件不兼容。
  • 对于你提到的问题,从代码和LD文件来看,似乎应该没有与编译器相关的问题。问题似乎是由于链接器无法正确处理分配给堆的内存空间而引起的。在链接器脚本中,你将__HEAP_SIZE设置为0,则链接器可以成功处理连接过程,这表明 __HEAP_SIZE 的赋值有可能存在问题。建议你检查一下是否正确指定了堆大小以及是否有其他错误导致了内存分配问题。如果还存在问题,请提供更多信息以供我进行更详细的分析。

CLANG和GCC的LD文件并不完全兼容,因为二者的实现有所不同。LD文件是链接器(linker)的配置文件,它描述了如何将目标文件(object file)链接成可执行文件或共享库。CLANG和GCC都有自己的链接器,因此它们的LD文件也有所不同。

虽然CLANG和GCC的LD文件不完全兼容,但它们的语法和结构是相似的,因此可以在一定程度上互相转换或者进行修改。但是,这需要根据具体情况进行适当的调整,以确保生成的可执行文件或共享库能够正确地工作。

CLANG和GCC的LD文件是不完全兼容的,因为它们使用不同的语法和指令。在本例中,CMSIS5.9.0的LD文件是为GCC编译器编写的,而使用CLANG编译器时会出现连接错误。
具体来说,CLANG编译器不支持__HEAP_SIZE这个符号,因此在执行ld.lld命令时会出现连接错误。而将__HEAP_SIZE设为0可以解决这个问题,因为这样就不会使用这个符号了。
因此,如果要在使用CLANG编译器时使用CMSIS5.9.0的LD文件,需要对LD文件进行修改,以使其与CLANG编译器兼容。或者,可以使用适用于CLANG编译器的LD文件。