Re: Warning from avr-gcc

[Bob von Knobloch]

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
> LDFLAGS = -Wl,-M
> 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.
>
> Erik
>
> (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,

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