[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Warning from avr-gcc

From: Bob von Knobloch
Subject: Re: Warning from avr-gcc
Date: Wed, 24 Mar 2021 09:17:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

On 24/03/2021 03:08, dvalin@internode.on.net wrote:

On 03.03.21 16:47, Bob von Knobloch wrote:
 > >
 > > On 2021-02-22 21:12, Bob von Knobloch wrote:
 > > >
 > > > "/usr/lib64/gcc/avr/7/ld: warning: -z relro ignored"
 > > >

 > OK, it it a feature to make relocated code read-only under certain
> circumstances (does not apply to my AVR Mega1284). It seems to be built into
 > the avr-ld linker program.
 > issuing "avr-ld" gives:
 > avr-ld: warning: -z relro ignored
 > avr-ld: no input files
 > So the linker seems to have this default.

Yes, "-z relro" asks ***-ld to " Create an ELF PT_GNU_RELRO segment
header in the object." It seems safe to infer that the avr-ld back end
isn't equipped to do that.

If the warning happens with legitimate input files, I'd report a minimal
use case which causes avr-gcc to invoke avr-ld with "-z relro", for a
bug fix. If it only happens with no input files, then it's only a
cosmetic issue, I figure.

> I suspected it because an old program compiled with avr-gcc 4.9.2 does not > run when compiled with version 7.4.0, although it compiles without error. I
 > will have to dig deeper.

Whether it's the spurious linker option mucking up the code, or another
bug, I'd run an "avr-gcc -c" to only compile and assemble, then manually run
avr-ld, so there's no "-z relro". That would test the later toolchain
utilities individually. (On my most recent project I only have
so it can find libgcc.a, nothing more. But that is an old toolchain, I
must admit.)

If that doesn't just work, then I'd be tempted to run "avr-gcc -S" with both versions, then diff the generated assembler intermediate source files. But there could be any number of differences due only to differing attempts at optimisation. The
quickest way to debugmay be to ifdef out 95% of the code, running only a
LED blinker in the scheduling loop, then add chunks till it falls over.

There's something to be said for retaining an old toolchain version for
an old project when this stuff happens. Backward compatibility is a
priority with gcc and binutils maintainers, but oversights happen.

Apologies if this post doesn't thread, I'm currently limited to a
horrible webmail monstrosity.


(Will have to get back to this stuff, to finish off some networked LED
light dimmers for the rural off-grid owner-build which passed occupancy
inspection the day before yesterday. Phew, time on my hands, almost.)

Hi Erik,
thanks for the reply.
There are 2 things:

1 '-z relro'
This, as far as I can determine, is purely cosmetic and can be ignored once one knows this.

2. Non-compilation of an old project.
I took my 'link.ld' (which had been carefully crafted - with your help) and cut and pasted my parts into a new default linkscript for the correct AVR family and this works fine. The mismatch of old linkscript and new linker was putting code at location '0' (where the vectors should be. I didn't investigate further, as it seems pointless. Compiling a project without externally linked code is fine in both cases.

Hope you didn't get hit by the flooding (I've forgotten your exact location and it's a big country):
All the best,

The Sun is out, the sky is blue, it's time to drive the MR2.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]