This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Warnings regarding errata fixed and mapping symbol missing
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Egor Pasko <pasko at google dot com>
- Cc: Han Shen <shenhan at google dot com>, Luis Lozano <llozano at google dot com>, binutils <binutils at sourceware dot org>
- Date: Thu, 2 Jul 2015 13:19:38 -0700
- Subject: Re: Warnings regarding errata fixed and mapping symbol missing
- Authentication-results: sourceware.org; auth=none
- References: <CACkGtrhYpt7P_S=fJC30tESm6tCtA=gvES8o3ANBscQfGcyUiA at mail dot gmail dot com> <CAJimCsFF6qhGuwa4xstoM01cZLoeoqMfXeLLiO=_dUsw07K7ag at mail dot gmail dot com> <CAH3q7_=m4Uj0KP0jpYOMWeQkYAN5yAhWOtmcw3K8Rzty5HGqZQ at mail dot gmail dot com>
> I am looking into using aarch64-gold for Chrome, where the general
> approach is to treat warnings as errors, except explicit list of
> warnings for which "we know what we are doing".
>> For the warning about missing mapping symbols, it seems to me that the
>> warning is justified -- if you ask it to scan for errata, but you
>> can't, the user ought to be told about it. Why is that not something
>> that should be fixed on the compiler side? If it's considered a normal
>> case, and an absence of mapping symbols implies that the linker
>> doesn't *need* to scan that section for errata, then just remove the
>> warning. But if there's a real possibility that the section might have
>> instruction sequences that need stubs, I'd want to keep the warning,
>> and pressure the compiler to fix it.
>
> In Chromium/Chrome we would prefer _not_ to use --no-fatal-warnings
> when switching to ld.gold. Can something like
> --no-cortex-a53-errata-XXXX-warning be introduced in gold?
Either the warnings are useful or they're not. If useful, they point
to something that should be fixed in the compiler; if not, we should
just drop the warnings completely. I'd prefer not to have an option to
disable one specific warning.
> As far as I understand, currently ld.bfd does not warn about missing
> mapping symbols. So there is an argument for maintaining consistency
> with ld.bfd.
>
> Looking at a few examples of missed mapping symbols: I saw some of
> those not being output sometimes for data sections by GAS, but I am
> not confident enough to assert that this only happens for non-code
> sections. Not sure what to do, this makes the process of patching for
> errata look unreliable.
That doesn't quite sound like it falls under the "we know what we are
doing" category, does it?
The psABI (AAELF) says this about mapping symbols:
4.6.5.1 Section-relative mapping symbols
Mapping symbols defined in a section define a sequence of
half-open address intervals that cover the address range of the
section. Each interval starts at the address defined by the
mapping symbol, and continues up to, but not including, the
address defined by the next (in address order) mapping symbol or
the end of the section. A section must have a mapping symbol
defined at the beginning of the section; however, if the section
contains only data then the mapping symbol may be omitted.
That makes it pretty clear that, in the absence of a mapping symbol,
the entire section can be treated as data. Unless there's a well-known
toolchain that's breaking this rule, *and we want gold to point it
out*, I'd say these warnings should simply be dropped. A patch to do
that is pre-approved.
-cary