[Top][All Lists]

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

Re: Warning from avr-gcc

From: dvalin
Subject: Re: Warning from avr-gcc
Date: Wed, 24 Mar 2021 12:38:08 +1030

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.)

reply via email to

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