bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/19106] New: os_region_check() is called to early


From: christian.eggers at kathrein dot de
Subject: [Bug ld/19106] New: os_region_check() is called to early
Date: Fri, 09 Oct 2015 12:49:53 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=19106

            Bug ID: 19106
           Summary: os_region_check() is called to early
           Product: binutils
           Version: 2.25
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: christian.eggers at kathrein dot de
                CC: ceggers at gmx dot de
  Target Milestone: ---
              Host: x86_64-suse-linux
            Target: arm-cortexm-eabi

On a target with a nearly full flash ld fails with

myprog.elf: section `ARM' will not fit in region `FLASH'
region `FLASH' overflowed by -2976 bytes

The negative number looks suspicious for me, because this means that in fact
there is nearly 3k left in my FLASH region. When adding more code (or reducing
the region size), this number increases until it crosses zero and becomes
positive.

Interesting compiler switches (ld is called by gcc):
-Wl,-T,STM32.ld
-Wl,--gc-sections
-flto=jobserver
-fuse-linker-plugin

After adding some printfs() to ld, I reconstructed the following code flow:

lang_process()
+--lang_size_sections(*relax := NULL, check_regions := TRUE (!
RELAXATION_ENABLED));  // NOTE: relaxation is disabled
|  \--one_lang_size_section_pass(*relax := NULL, check_regions := TRUE);
|     \--lang_size_sections_1(.., .., .., .., *relax := NULL, check_regions :=
TRUE);
|        \--os_region_check(..)  // BANG !!! region->had_full_message = TRUE;
einfo(...will not fit in region...);
|
+--ldemul_after_allocation();
|  \--ld_emulation->after_allocation()
|     [gldarmelf_after_allocation()]
|     \--gldarmelf_map_segments(need_layout := TRUE)
|        \--[do ... while () loop with 2 iterations]
|           \--lang_relax_sections(need_layout := TRUE)  
|              \--lang_size_sections(*relax := NULL, check_regions := TRUE (!
RELAXATION_ENABLED));  // NOTE: relaxation is still disabled here
|                 \--one_lang_size_section_pass(*relax := NULL, check_regions
:= TRUE);
|                    \--lang_size_sections_1(.., .., .., .., *relax := NULL,
check_regions := TRUE);
|                       \--os_region_check(..);  // now the region does not
overflow, but region->had_full_message has already been set
|
\--lang_check_section_addresses()
   \--einfo(...region ... overflowed by ... bytes);  // number of bytes can be
negative here
      \--xexit(1)

It seems that os_region_check() is called during different "stages" of the link
process. During the 1st stage (lang_size_sections() is called directly from
lang_process()), the region `FLASH' actually overflows. During the second stage
(lang_size_sections() is called via the ldemul_after_allocation() path), the
required code size is a little bit smaller, so that everything would fit into
`FLASH'.

When I pass an additional -Wl,--relax the RELAXATION_ENABLED evaluates to TRUE
and os_region_check() is not called during the first stage. Is this case the ld
works fine (at least for this executable).

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

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