From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id F155338582B1 for ; Wed, 31 Aug 2022 19:21:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F155338582B1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x82b.google.com with SMTP id y18so11785825qtv.5 for ; Wed, 31 Aug 2022 12:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=IQzb0koRRK5X/qOy6JqcOjGkP1LmzyX8GXgtMgpC/uM=; b=i1TAe/KSLpH/Lpf5otnI2I6G9g3syYPa9RLNcbUuF24XkmBbWbHpb2g3JpQrH9Peh6 JadNY6JimfONh2Fk5GqRC+MqcoNI7H3rlPZIAyuNQRH8QiLSUxXcEPu6JZXrIA4kyh6J e1ZTWpEaNH1ggzjXF48e18fN7OqMExlBa72a/sbFPPOqt7wxPLnmKYZ+rfv9+FCzoMGH undIxXJbszq6VNtlid3G875KByaxHw6IQOP7t/0Yw/aW5VyiCXE+7SdQg5DM9+kp2PnQ ck2HK7jkeU3iWKk8EUgojG0pIqOF/X9NNJ0xti2Ai7B04198gdtaI9lzksO0tkCr99Pq sdMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=IQzb0koRRK5X/qOy6JqcOjGkP1LmzyX8GXgtMgpC/uM=; b=xgOE+c6TVIf8e20wByFUNEJ4cUGYeq5mT3lEp3vPXGYYxi89bOqI2eL1OB5BRP3gM8 yi7yK1m8aS/c3rLpeQ80Cyj1/8U5iXM+7rooKzChLfjGP1OoCtcu5vJN8x6RsEeBteL4 IdEWreR939iBJiEYfn1SwYxUxbfL81j8lS6pTkeTJRIjPTqZYZ5vBUVQhSOBKXtb86Rh 6obSkk0G5/znfa2a5deKMjSkBMdHYIui84Gm3W0GNd1sVwAc3CwzTbey8fwTAs1Wlvsd dk5ik+awcBn9s2Bv41LCApjXsCPslpLjALgRGYfGYFr4+9z2g/5fv8WmLOeVNlCd96KK lljQ== X-Gm-Message-State: ACgBeo25MDhJ+mRGpGmsOtDx5ylrOxxzWNMrrODEAv5O5Grg1eIazK0A BvRLg6rhuE6Cb1BQMn6wk4qOkrP9vzsch4kujXs= X-Google-Smtp-Source: AA6agR5Pbpe2eBt5+ZorMSfC3FZ4le92HJC7Vlofd7C+DDj9Q6muwRx5JqAKI1jJ/0muWQgCzhOTQcsSfUwKz5DjEJ8= X-Received: by 2002:a05:622a:44c:b0:343:7b8e:2cb with SMTP id o12-20020a05622a044c00b003437b8e02cbmr19790597qtx.617.1661973688264; Wed, 31 Aug 2022 12:21:28 -0700 (PDT) MIME-Version: 1.0 References: <199ec63c39a4a323e93402277c1cc67f5c8216bf.camel@xry111.site> In-Reply-To: From: "H.J. Lu" Date: Wed, 31 Aug 2022 12:20:52 -0700 Message-ID: Subject: Re: question: i386 ld.gold reports "internal error" linking files with SHT_RELA section To: Xi Ruoyao Cc: Pierre Labastie , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Aug 30, 2022 at 9:43 PM Xi Ruoyao wrote: > > On Tue, 2022-08-30 at 13:36 -0700, H.J. Lu wrote: > > > > > SHT_RELA shouldn't be used for i386. > > > > > > But it is accepted by ld.bfd... > > > > Do you have .o files for ld.bfd I can take a look at? > > > > > FWIIW, only the dwarf debug sections are generated as SHT_RELA by > > > nasm. > > Hi, > > $ cat t.asm > section .text > extern printf > global main > main: > push ebp > mov ebp, esp > push msg > call printf > add esp, 4 > leave > ret > > section .data > msg db 'Hello, world!', 13, 10, 0 > > section .note.GNU-stack noalloc noexec nowrite progbits > $ nasm t.asm -f elf32 -F dwarf > $ cc t.o && ./a.out > Hello, world! > $ cc -fuse-ld=gold t.o > /usr/bin/ld.gold: internal error in relocate_section, at ../../gold/i386.cc:3683 > collect2: error: ld returned 1 exit status > > I'll attach "t.asm' and "t.o.gz". > > -- > Xi Ruoyao > School of Aerospace Science and Technology, Xidian University What happened are 1. nasm generates RELA relocation for debug sections. But addend in RELA relocation is 0: Relocation section '.rela.debug_info' at offset 0x3a0 contains 5 entries: Offset Info Type Sym. Value Symbol's Name + Addend 00000006 00000501 R_386_32 00000000 .debug_abbrev + 0 0000000c 00000201 R_386_32 00000000 .text + 0 00000010 00000201 R_386_32 00000000 .text + 0 00000014 00000601 R_386_32 00000000 .debug_line + 0 0000002c 00000201 R_386_32 00000000 .text + 0 and addend is stored at the relocation offset like REL relocation: Hex dump of section '.debug_info': 0x00000000 31000000 02000000 00000401 00000000 1............... 0x00000010 12000000 00000000 782e7300 4e41534d ........x.s.NASM 0x00000020 20322e31 352e3035 00018002 00000000 2.15.05........ 0x00000030 00000000 00 2. ld.bfd treats RELA relocation like REL relocation. It uses addend at the relocation offset, not in RELA relocation. It just works with ld.bfd by accident. A linker, like gold, can disallow RELA relocation. A linker, like lld, can use addend in RELA relocation and addend at the relocation offset is ignored. -- H.J.