From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 4CBE73858C52 for ; Thu, 19 Jan 2023 11:45:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CBE73858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674128757; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=M8G7oOmnhAaVSMBaRDPTCQgzZyC1x6z1pVzuovtjfh4=; b=U3PoTOQLcUIHqvv0GcIEHaDWaT9rCXb50vs5r+lA4Sp3mmvcCG4U4t6rPt69N6Rpvu0fQ7 U6Dgodt6Xahzhivudv38fZdteoqCNgp33HOX/4kj9Q6ZaabYOCwghpKLeHYKlbhgP/4soM PJIdz5ynSubt2HHDH/naF8f5ea30B0U= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-656-vgbfUKXyP86CUEhrKRnB0Q-1; Thu, 19 Jan 2023 06:45:56 -0500 X-MC-Unique: vgbfUKXyP86CUEhrKRnB0Q-1 Received: by mail-qt1-f198.google.com with SMTP id r24-20020ac85e98000000b003b68b691996so818139qtx.13 for ; Thu, 19 Jan 2023 03:45:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:from:content-language :references:to:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M8G7oOmnhAaVSMBaRDPTCQgzZyC1x6z1pVzuovtjfh4=; b=jctrLAWWMMoqBOEoAmk01oMM+YE5cpn8ns5mTudGCRlOdKXV3K0SEf6gA9jgPVNHeT x9iPQbVf2IVTnNny5wB2N1RDKo2gqmZrC/dZiIvn8GnvgYDxj0kReUnSz7gziPcEZ117 P/EymaeExBX8yvrKHw89NbvVKM8wsnGPc7WzR4YADlFkSMvW6quhouX+Ir1nsBCvMaAB 5Ldh+whyfQOBazFXt00Alt9ZShgMuJ8ytu4CrWgD1Y5Mwyr/5LFpO3fthWgZsbvstO42 5XoJBIVfPffrqeO28CGcv5lMsDyQPviFKguJTQdyoAbflJlSKVWZvKdREo9BoYzBv1lb iI/w== X-Gm-Message-State: AFqh2kqCxQ4cS695G0ait4sBTaofwkG3bNpAjwa/9zhUYxnsXCYUYBGq a1Sx6WJ77gdyTqTlWG1DamfuUFENySb1rHn90Y2pIrvWp5/Oarzc1NMV4sBBNLNpPdpT66nBbGg etoVo3Ecmm+RmLv34ow== X-Received: by 2002:ac8:4a18:0:b0:3b6:8d44:5648 with SMTP id x24-20020ac84a18000000b003b68d445648mr4148140qtq.46.1674128755835; Thu, 19 Jan 2023 03:45:55 -0800 (PST) X-Google-Smtp-Source: AMrXdXtbk/6EsGhpcuBT4zq2C6pJ4C7LqL2nrXQziVXWr7D5guECBYeYHkFejTKIn6Z8AR3hJFO8Aw== X-Received: by 2002:ac8:4a18:0:b0:3b6:8d44:5648 with SMTP id x24-20020ac84a18000000b003b68d445648mr4148118qtq.46.1674128755591; Thu, 19 Jan 2023 03:45:55 -0800 (PST) Received: from [192.168.1.18] ([79.123.83.169]) by smtp.gmail.com with ESMTPSA id v21-20020ac87295000000b003a5430ee366sm817925qto.60.2023.01.19.03.45.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 19 Jan 2023 03:45:54 -0800 (PST) Message-ID: Date: Thu, 19 Jan 2023 11:45:52 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 To: Orlando Arias , binutils@sourceware.org References: From: Nick Clifton Subject: Re: RWX load segment MSP430 back-end In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,BODY_8BITS,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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: Hi Orlando, > I ran into a rather puzzling issue with ld.bfd for the MSP430 target For problems like this it is really best if you can file a bug report with the binutils bugzilla system. That way, if there is an issue, we can track it, and future readers can search for the solution. > /usr/bin/msp430-elf-ld: warning: binary.elf has a LOAD segment with RWX permissions > $ msp430-elf-readelf -l binary.elf > Program Headers: >   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align >   LOAD           0x000000 0x0000c14c 0x0000c14c 0x0016e 0x0016e RWE 0x4 If you add the -S option to the msp430-elf-readelf command, it will also tell you which sections are mapped to that segment: Section to Segment mapping: Segment Sections... 00 .rodata2 .text > Well, indeed there is something that gets placed at 0xc14c that is read write and executable. However, the MSP430FR5739 has nothing on that memory region! In fact, looking > at the linker scripts reveals nothing that should be placed there, unless I am missing something of course. This does assume that the linker script for the msp430fr5397 has been used. It is possible that a different script it being used. Adding -v to the final msp43-elf-gcc command line should you check that. Even better if you add -Wl,-Map,binary.map the linker will create a map file (called binary.map) which will show you what went where during the link. > In any case, I have no idea where extraneous segment is coming from. My best guess is that the segment is meant to map onto the FRAM of the MSP430FR5739. But for some reason the segment's start address is being pushed backwards to earlier in memory. No idea why. > I did notice that a patch was submitted to treat the cris*-elf backend in a special way by defaulting to --no-warn-rwx-segment which I > guess could be done as well for the MSP430. That could be done. But it is only a warning message - it should not affect the outcome of the link at all. (I should also note that there is a configure-time option to disable this warning, so it is possible to build a msp430-elf-ld which does not warn, without adding any patches to the binutils sources). Of course if your programs are working, then you can safely ignore this issue. (Assuming that there are no security concerns over the writeable, executable memory). You can always add -Wl,--no-warn-rwx-segment to the gcc command line if you want to turn off the warning. If you are worried however then please refile this email as a bug report, and if you can, include a copy of the linker map and linker script. Cheers Nick