[Bug ld/29741] AVR ld unable to link for 0-series MCUs

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |2.40
 CC||gjl at gcc dot gnu.org

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

[Bug binutils/31704] [avr] Support avr-objdump -P avr-deviceinfo

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |2.43

--- Comment #3 from Georg-Johann Lay  ---
Added in v2.43

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

[Bug binutils/31687] [avr] Output of avr-objdump -P mem-usage missing .rodata

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |2.43
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Georg-Johann Lay  ---
Fixed in v2.43

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

[Bug binutils/31704] [avr] Support avr-objdump -P avr-deviceinfo

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 15527
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15527=edit
Proposed patch

AVR: binutils/31704 - Let avr-objdump show .note.gnu.avr.deviceinfo

This patch supports

 avr-objdump -P avr-deviceinfo

which displays the contents of the .note.gnu.avr.deviceinfo section,
which is added by the startup code from AVR-LibC in crt.o.

binutils/
PR binutils/31704
* od-elf32_avr.c (OPT_AVRDEVICEINFO): New macro.
(objdump_private_option options): Set [2] to "avr-deviceinfo".
(elf32_avr_help): Help on new -P avr-deviceinfo.
(elf32_avr_dump) [OPT_AVRDEVICEINFO]: Run...
(elf32_avr_dump_avr_deviceinfo): ...this new static function.

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

[Bug binutils/31687] [avr] Output of avr-objdump -P mem-usage missing .rodata

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Created attachment 15526
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15526=edit
Proposed patch

AVR: binutils/31687 - Include .rodata size in avr-objdump -P mem-usage.

AVR emulations with a .rodata output section were missing the
size of that section in  avr-objdump -P mem-usage.  These are
the emulations that keep .rodata in program memory, which can
be supported by devices that see (a part of) the program memory
in the RAM address space.

The patch also introduces a code clean-up related to PR 27283,
which was about broken binaries that lead to overflow / UB in
size computation.  The section size is now just truncated or
saturated, alongside with a diagnostic about the truncation and
*which* section length is being truncated.

binutils/
PR binutils/31687
* od-elf32_avr.c (elf32_avr_get_truncated_size): New static function.
(elf32_avr_get_memory_usage): Use it to get (truncated) section sizes.

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

[Bug binutils/31704] [avr] Support avr-objdump -P avr-deviceinfo

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr

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

[Bug binutils/31704] New: [avr] Support avr-objdump -P avr-deviceinfo

[gjl at gcc dot gnu.org]

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

Bug ID: 31704
   Summary: [avr] Support avr-objdump -P avr-deviceinfo
   Product: binutils
   Version: 2.42
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

The startup code from AVR-LibC contains a .note.gnu.avr.deviceinfo section that
contains properties of the AVR device for which it has been compiled.  It would
be a nice extension to be able to display that information with, say,

avr-objdump -P avr-deviceinfo file.elf

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

[Bug binutils/31687] [avr] Output of avr-objdump -P mem-usage missing .rodata

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Created attachment 15494
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15494=edit
Test case for AVR128DA32

$ avr-objdump -h avr128da32.elf 

avr128da32.elf: file format elf32-avr

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .data   00804000  00d2  0166  2**0
  CONTENTS, ALLOC, LOAD, DATA
  1 .text 00d2      0094  2**1
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata   000a  00a08000  00018000  0166  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA

$ avr-objdump -P mem-usage avr128da32.elf 

avr128da32.elf: file format elf32-avr
AVR Memory Usage

Device: avr128da32

Program: 210 bytes (0.2% Full)
(.text + .data + .bootloader)

Data:  0 bytes (0.0% Full)
(.data + .bss + .noinit)

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

[Bug binutils/31687] [avr] Output of avr-objdump -P mem-usage missing .rodata

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 15493
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15493=edit
attiny40.elf

Test case for ATtiny40

$ avr-objdump -h attiny40.elf 

attiny40.elf: file format elf32-avr

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 0040      0094  2**1
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata   000a  4040  0040  00d4  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data   00800040  004a  00de  2**0
  CONTENTS, ALLOC, LOAD, DATA

$ avr-objdump -P mem-usage attiny40.elf 

attiny40.elf: file format elf32-avr
AVR Memory Usage

Device: attiny40

Program:  64 bytes (1.6% Full)
(.text + .data + .bootloader)

Data:  0 bytes (0.0% Full)
(.data + .bss + .noinit)

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

[Bug binutils/31687] [avr] Output of avr-objdump -P mem-usage missing .rodata

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P2  |P3
 Target||avr

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

[Bug binutils/31687] New: [avr] Output of avr-objdump -P mem-usage missing .rodata

[gjl at gcc dot gnu.org]

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

Bug ID: 31687
   Summary: [avr] Output of avr-objdump -P mem-usage missing
.rodata
   Product: binutils
   Version: 2.42
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

As is appears, objdump deas ot consider output section .rodata.

.rodata output section is only present on emulations avrtiny, avrxmega3,
avrxmega2_flmap and avrxmega4_flmap.

For example, for some avrxmega3 device with the following

$ avr-objdump -h foo.elf

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .data 001c  00802800  015f  0213  2**0
  CONTENTS, ALLOC, LOAD, DATA
  1 .text 0158      00b4  2**1
  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata   0007  4158  0158  020c  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .bss  0008  0080281c  0080281c  022f  2**0
  ALLOC
  4 .noinit   0001  00802824  00802824  022f  2**0
  ALLOC

Which are the following sizes in decimal:

.data   = 28
.text   = 344
.rodata = 7
.bss= 8
.noinit = 1

The expected flash consumption is .text + .data + .rodata = 379 bytes, and RAM
consumption is .data + .bss + .noinit = 37 bytes.

The report from avr-size is correct:

   textdata bss dec hex filename
351  28   9 388 184 foo.elf

but the report from avr-objdump -P mem-usage is not:

AVR Memory Usage

Device: atmega4808

Program: 372 bytes (0.8% Full)
(.text + .data + .bootloader)

Data: 37 bytes (0.6% Full)
(.data + .bss + .noinit)

The "Program" size is missing .rodata.

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

[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=31321

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

[Bug ld/31321] AVR: Remove PROVIDE from definition of symbol __flmap_init_label

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |2.43
 Status|NEW |RESOLVED
 Target||avr
   Priority|P2  |P3
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=31124
 Resolution|--- |FIXED

--- Comment #1 from Georg-Johann Lay  ---
Resolved in v2.43:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=24f5deb64d9b0c33280108f185d03ff7dfef30ce

Resolved in v2.42.1:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2fad36c3f553d103fcd0b75abd7a17da89b99864

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

[Bug ld/31321] New: AVR: Remove PROVIDE from definition of symbol __flmap_init_label

[gjl at gcc dot gnu.org]

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

Bug ID: 31321
   Summary: AVR: Remove PROVIDE from definition of symbol
__flmap_init_label
   Product: binutils
   Version: 2.42
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

PR31124 introduced symbol __flmap_init_label as:

PROVIDE (__flmap_init_label = DEFINED(__flmap_init_start) ? __flmap_init_start
: 0) ;

for emulations avrxmega2_flmap and avrxmega4_flmap.

The symbol is supposed to be used by the startup-code crt*.o from AVR-LibC: The
symbol resolves to:

* __flmap_init_start when NVMCTRL_CTRLB.FLMAP should be initialized according
to __flmap_value_with_lock, which is the case for emulations avrxmega2/4_flmap.

* __flmap_noinit_start when the startup code should bypass the initialization
of NVMCTRL_CTRLB.FLMAP, which is the case for emulations avrxmega2/4.

All this works as expected, except in the case when such a crt*.o is used with
a version of Binutils that does not implement PR31124.  This can happen when
crt*.o is deployed as part of a device pack that's build with PR31124 but used
with a toolchain that does not have PR31124.  In such a case, linking will
throw an undefined reference to __flmap_init_label.

The obvious fix would be to provide a default for that symbol in gcrt1.S like:

.weak __flmap_init_label
.set  __flmap_init_label, __flmap_noinit_start

which solves the undefined reference, however __flmap_init_label ceases to work
when PR31124 *IS* supported, because the PROVIDE (__flmap_init_label =
__flmap_init_start) won't touch the already defined __flmap_init_label, hence
init of NVMCTRL_CTRLB.FLMAP would be bypassed when it must not be bypassed.

Hence, remove PROVIDE from __flmap_init_label.

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

[Bug ld/31177] AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |2.42

--- Comment #2 from Georg-Johann Lay  ---
Added in 2.42

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

[Bug ld/31177] AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Severity|normal  |enhancement

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

[Bug ld/31177] AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P2  |P3

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

[Bug ld/31177] AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |gjl at gcc dot gnu.org
 Target||avr

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

[Bug ld/31177] New: AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text

[gjl at gcc dot gnu.org]

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

Bug ID: 31177
   Summary: AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY
region text
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

The start of MEMORY region text currently starts hard-coded at 0.

The linker can produce more exact diagnostics when it knows the exact
placements of the memory regions.

For some old devices, program memory starts at 0x8000, so allow to specify
program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region
is described.

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

[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |2.42

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

[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/PR11294
   ||4

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

[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Georg-Johann Lay  ---
Closed as completed.

See also https://gcc.gnu.org/PR112944

Below is a snip from the new comments in ./ld/scripttempl/avr.sc:

___

HAVE_FLMAP
==

The .rodata section is located in program memory. Devices from
the AVR64* and AVR128* families (from avrxmega2 and avrxmega4)
see a 32k segment of their program memory in their RAM address
space.  Which 32k segment is visible is determined by the
bit-field NVMCTRL_CTRLB.FLMAP.
Output section .rodata is placed in MEMORY region rodata.
The LMA of the .rodata section can be set by means of:

__RODATA_FLASH_START__ specifies the byte address of the
rodata LMA.

__flmap specifies which 32k block is visible in RAM provided
__RODATA_FLASH_START__ is undefined
When __flmap and __RODATA_FLASH_START__ are undefined, then an
emulation-specific default is used (the last 32k block).


MAYBE_FLMAP
===

For devices from avrxmega2 and avrxmega4: The user can chose whether
or not .rodata is located in flash (if HAVE_FLMAP) or located in
in RAM (if not HAVE_FLMAP by means of -mrodata-in-ram).  This is
achieved by new emulations avrxmega2_flmap and avrxmega4_flmap that
are selected by compiler option -mno-rodata-in-ram.

In order to facilitate initialization of NVMCTRL_CTRLB.FLMAP and
NVMCTRL_CTRLB.FLMAPLOCK in the startup code irrespective of
HAVE_FLMAP, the following symbols are used / defined in order to
communicate with the startup code.
Notice that the hardware default for FLMAP is the last 32k block,
so that explicit initialization of FLMAP is only required when the
user wants to deviate from the defaults.

__flmap = HAVE_FLMAP
  ? given by __flmap resp. __RODATA_FLASH_START__ >> 15
  : 0;

__flmap_value = __flmap << __flmap_bpos;

__flmap_value_with_lock = __flmap__value | __flmap_lock_mask;

__flmap_init_label = HAVE_FLMAP
 ? __flmap_init_start
 : __flmap_noinit_start;
Supposed to be used as a jump target for RJMP so that the code
can initialize FLMAP / skip initialization of FLMAP depending
on the chosen emulation, and without the need to support two code
versions of crt.o for the two possible emulations.

__flmap_lock is a bool provided by the user when FLMAP should be
protected from any further changes.

__flmap_lock_mask is an 8-bit mask like NVMCTRL_FLMAPLOCK_bm
provided by the user which is set in __flmap_value_with_lock
when __flmap_lock is on.

__do_init_flmap = HAVE_FLMAP ? 1 : 0;
Whether or not FLMAP is supposed to be initialized according
to, and for the purpose of, .rodata in flash.

Apart from that, the compiler (device-specs actually) defines the
following macros:

__AVR_HAVE_FLMAP__
Defined if a device has the NVMCTRL_CTRLB.FLMAP bitfield
*AND* if it's unknown at compile-time / assembler-time whether
emulation avrxmega* is used or avrxmega*_flmap.

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

[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Assignee|unassigned at sourceware dot org   |gjl at gcc dot gnu.org

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

[Bug ld/31124] AVR: Support new Emulations for Devices with FLMAP

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
Version|unspecified |2.42 (HEAD)
Summary|AVR: Support new Emulations |AVR: Support new Emulations
   |for devices with FLMAP  |for Devices with FLMAP
   Priority|P2  |P3
   Severity|normal  |enhancement
   Keywords||performance

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

[Bug ld/31124] New: AVR: Support new Emulations for devices with FLMAP

[gjl at gcc dot gnu.org]

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

Bug ID: 31124
   Summary: AVR: Support new Emulations for devices with FLMAP
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Devices from the AVR64* and AVR128* families (from avrxmega2 and avrxmega4)
see a 32 KiB portion of their program memory in the RAM address space.

Which 32 KiB segment is visible is determined by the bit-field
NVMCTRL_CTRLB.FLMAP.

This can be used to place .rodata in flash (it's currently located in RAM like
for all other AVR devices, except the ones from avrtiny and avrxmega3).

* The user should be able to chose the old .rodata location by means of
  a command line option like, say -mrodata-in-ram.  This is needed
  to return to the current behaviour with rodata in RAM if desired.

* The user may chose which 32 KiB block holds the rodata section.

* Provide symbols so that the startup code from AVR-LibC is able to set
  up NVMCTRL_CTRLB.FLMAP that controls which 32 KiB block is visible in
  the RAM address space.

* New (default) linker description files are needed.  This requires new
  emulations like avrxmega2_flmap and avrxmega4_flmap.

* The startup-code from AVR-LibC should work irrespective of the chosen
  emulation, so that we retain the one-crt-per-device policy for simplicity.

* In all cases, the default configurations should work correctly without any
  user interventions / special code, irrespective of -m[no-]rodata-in-ram.

* The multilib structure is unchanged.

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

[Bug ld/21472] [avr] Add new emulation for ATtiny416 et al.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Georg-Johann Lay  ---
Added in 2.29

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14406] Support .progmem.data sections to work with GCC's PR49868

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Georg-Johann Lay  ---
Closed as WON'T FIX as explained in comment #2

(In reply to comment #0)
> Moreover, the default linker script should change
>   *(.progmem*)
> to
>   *(.progmem)
>   *(.progmem.*)

This was already implemented by PR21849 that moved .progmemx.data (used by
__memx) to higher addresses.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14406] Support .progmem.data sections to work with GCC's PR49868

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Created attachment 11148
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11148=edit
Augmentation of default linker script. Link with -Tflash12.ld

WON'T FIX this one:

The layout of code and data highly depends on the requirements of a project,
and supplying a default layout would most likely introduce assumptions that and
not appropriate and would conflict with the assumptions of most projects.

Hence, it's best not to introduce such assumptions and leave it up to the user
to design code and data layout for a project if it uses __flashN. Basically,
there are 2 appoaches:

1) Supply a project-specific linker script.

2) Augment the default linker script.  Example: Suppose the application only
needs __flash1 and / or __flash2, and the corresponding sections
.progmem1.data, .progmem2.data should be located after .text, i.e. after all
code, jumptables and data from __memx but before the initializers for .data. 
Then you can augment the default linker script by linking with -Tflash12.ld
where flash12.ld is the attached text file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21849] [avr] Locate .progmemx at a higher address.

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 10290
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10290=edit
proposed patch

ld/
PR ld/21849
* scripttempl/avr.sc: Split .progmemx.* from .progmem.* and locate
former at a higher address.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21849] [avr] Locate .progmemx at a higher address.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P2  |P3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21849] New: [avr] Locate .progmemx at a higher address.

[gjl at gcc dot gnu.org]

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

Bug ID: 21849
   Summary: [avr] Locate .progmemx at a higher address.
   Product: binutils
   Version: 2.29
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

avr-gcc puts data for named address space __memx into section .progmemx.  The
current linker script has a catch-all .progmem* located at a lower address
together with data that is expected to reside in the lower 64 KiB flash
segment.

This is not required for __memx data so that .progmemx. can be moved to a
higher address, wasting less of the small addresses.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21472] [avr] Add new emulation for ATtiny416 et al.

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Created attachment 10237
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10237=edit
binutils-avrxmega3-pr21472-doc.diff: Round-up of documentation.

gas/
PR ld/21472
* config/tc-avr.c (mcu_types): Add entries for: attiny212,
attiny214, attiny412, attiny414, attiny814, attiny1614,
attiny1616, attiny1617, attiny3214, attiny3216, attiny3217.
(md_show_usage): Adjust doc for "avrxmega3".
* doc/c-avr.texi (AVR options) [-mmcu=]: Adjust doc for avrxmega3.
Add MCUs: attiny212, attiny214, attiny412, attiny414, attiny416,
attiny417, attiny814, attiny816, attiny817, attiny1614,
attiny1616, attiny1617, attiny3214, attiny3216, attiny3217.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21683] [avr] Support a pseudo-instruction to allow more efficient GCC ISR prologues

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |2.29

--- Comment #3 from Georg-Johann Lay  ---
Done.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21683] [avr] Support a pseudo-instruction to allow more efficient GCC ISR prologues

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 10232
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10232=edit
bin-pr21683-gccisr.diff: Proposed patch.

/
PR gas/21683
* include/opcode/avr.h (AVR_INSN): Add one for __gcc_isr.

gas/
PR gas/21683
* doc/c-avr.texi (AVR Options) <-mgcc-isr>: Document it.
(AVR Pseudo Instructions): New node.

* config/tc-avr.h (md_pre_output_hook): Define to avr_pre_output_hook.
(md_undefined_symbol): Define to avr_undefined_symbol.
(avr_pre_output_hook, avr_undefined_symbol): New protos.

* config/tc-avr.c (struc-symbol.h): Include it.
(ISR_CHUNK_Done, ISR_CHUNK_Prologue, ISR_CHUNK_Epilogue): New enums.
(avr_isr, avr_gccisr_opcode)
(avr_no_sreg_hash, avr_no_sreg): New static variables.
(avr_opt_s) : Add field.
(avr_opt): Add initializer for have_gccisr.
(enum options) : Add enum.
(md_longopts) <"mgcc-isr">: Add entry.
(md_show_usage): Document -mgcc-isr.
(md_parse_option) [OPTION_HAVE_GCCISR]: Handle it.
(md_undefined_symbol): Remove.
(avr_undefined_symbol, avr_pre_output_hook): New fuctions.
(md_begin) : Initialize them.
(avr_operand) : Add argument and set *pregno if function
is called for a register constraint.
[N]: Handle constraint.
(avr_operands) : Pass 5th parameter to calls.
[avr_opt.have_gccisr]: Call avr_update_gccisr.  Call
avr_gccisr_operands instead of avr_operands.
(avr_update_gccisr, avr_emit_insn, avr_patch_gccisr_frag)
(avr_gccisr_operands, avr_check_gccisr_done): New static functions.

* testsuite/gas/avr/gccisr-01.d: New test.
* testsuite/gas/avr/gccisr-01.s: New test.
* testsuite/gas/avr/gccisr-02.d: New test.
* testsuite/gas/avr/gccisr-02.s: New test.
* testsuite/gas/avr/gccisr-03.d: New test.
* testsuite/gas/avr/gccisr-03.s: New test.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21683] [avr] Support a pseudo-instruction to allow more efficient GCC ISR prologues

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P2  |P3
   Assignee|unassigned at sourceware dot org   |gjl at gcc dot gnu.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21683] New: [avr] Support a pseudo-instruction to allow more efficient GCC ISR prologues

[gjl at gcc dot gnu.org]

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

Bug ID: 21683
   Summary: [avr] Support a pseudo-instruction to allow more
efficient GCC ISR prologues
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Background: avr-gcc currently generated ISR prologues and epilogues less
efficient than possible.  This is due to avr back-end design and decisions. 
Solving this in avr-gcc alone would be inappropriately amount of work and
instability, maybe even reducing code performance in other places than ISRs. 
This is the reason for why

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20296

is open for > 12 years now and has been suspended.

A comined GCC + GAS approach would be feasible, and this PR is the GAS part:

GAS implements a __gcc_isr pseudo-instruction which scans the code and emits
parts of ISR prologue and epilogue.

__gcc_isr 1: GAS will replace it by an ISR prologue chunk (at most 6 insns).

__gcc_isr 2: GAS will replace it by an ISR epilogue chunk (at most 5 insns).

__gcc_isr 0, Rx:  Scan the code since the last prologue chunk and replace all
encountered prologue and epilogue chunks by appropriate code. Rx is general
purpose register.

During parse (md_assemble), prologue and epilogue chunks are represented as
rs_machine_dependent fragments.  If "__gcc_isr 0, Rx" is seen, all
rs_machine_dependent fragments in the current chain are transformed into
ordinary rs_fill code fragments of then known fixed size.

After parse (md_pre_output_hook) a sanity check is performed which reports any
dangling chunks.

__gcc_isr is only available with the new command line option -mgcc-isr

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21621] [avr] Wrong / missing warning "skipping two-word instruction"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P2  |P3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21621] [avr] Wrong / missing warning "skipping two-word instruction"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21621] New: [avr] Wrong / missing warning "skipping two-word instruction"

[gjl at gcc dot gnu.org]

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

Bug ID: 21621
   Summary: [avr] Wrong / missing warning "skipping two-word
instruction"
   Product: binutils
   Version: 2.29 (HEAD)
Status: NEW
  Severity: minor
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

$ avr-as frag.s -o frag.o && avr-objdump -d frag.o

== frag.s ==

.text
cpse 0,0
.subsection 1
lds 0,0
.previous
clc


.text
cpse 1,1
.subsection 1
sec
.previous
lds 1,1

== gas output ==

frag.s: Assembler messages:
frag.s:4: Warning: skipping two-word instruction


The first snip should *not* issue a skip warning whereas the second one
*should* issue one for the last line.  Due to the .subsection, the insn
following CPSE in the source is not the one which is skipped.

FYI, objdump's ouput is:

 <.text>:
   0:   00 10   cpser0, r0
   2:   88 94   clc
   4:   11 10   cpser1, r1
   6:   10 90 01 00 lds r1, 0x0001  ;  0x81
   a:   00 90 00 00 lds r0, 0x  ;  0x80
   e:   08 94   sec


The problem is in tc-avr.c::avr_operands() which holds static state on previous
opcode in "prev".  However, this state should go into the current fragment's
target-specific info in .tc_frag_data. (The right place would actually be the
respective fragment chain, not the fragment itself, but the chain doesn't allow
to add target-specific extensions whereas struct frag does.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21569] [avr] Make avr.sc so generic that there is no need for avrtiny.sc.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |2.29

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21569] [avr] Make avr.sc so generic that there is no need for avrtiny.sc.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Georg-Johann Lay  ---
Done.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21583] [avr] Move .jumptables to a higher address

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
(In reply to Nick Clifton from comment #1)
> Do you have a patch for the linker script to implement this addition ?

It's here: https://sourceware.org/ml/binutils/2017-06/msg00148.html

Am usually fileing PRs for additions so it's easier to refer to a feature.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21583] [avr] Move .jumptables to a higher address

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P2  |P3
   Assignee|unassigned at sourceware dot org   |gjl at gcc dot gnu.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21583] New: [avr] Move .jumptables to a higher address

[gjl at gcc dot gnu.org]

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

Bug ID: 21583
   Summary: [avr] Move .jumptables to a higher address
   Product: binutils
   Version: 2.29 (HEAD)
Status: NEW
  Severity: minor
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Currently, avr-gcc does not use .jumptables, but I intent to move jump-tables
out of .text again, cf.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81075

My plan is to use .jumptables for that.  As avr-gcc won't make any assumption
on the location, its best to put it after .text to save small flash addresses
for other purposes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21569] [avr] Make avr.sc so generic that there is no need for avrtiny.sc.

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 10093
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10093=edit
Proposed patch

ld/
Genericize avr.sc so that it also works for avrtiny.

* scripttempl/avrtiny.sc: Remove file.

* Makefile.am (eavrtiny.c): Depend on avr.sc, no more on avrtiny.sc.
* Makefile.in: Regenerate.
* emulparams/avrtiny.sh (SCRIPT_NAME): Set var to "avr".
(TEXT_ORIGIN): Remove var.
(FUSE_NAME, FUSE_LENGTH, LOCK_LENGTH, SIGNATURE_LENGTH)
(RODATA_PM_OFFSET): Set new vars.
* emulparams/avr1.sh (FUSE_NAME, EEPROM_LENGTH, FUSE_LENGTH)
(LOCK_LENGTH, SIGNATURE_LENGTH, USER_SIGNATURE_LENGTH): Set new vars.
* emulparams/avr2.sh: Same.
* emulparams/avr25.sh: Same.
* emulparams/avr3.sh: Same.
* emulparams/avr31.sh: Same.
* emulparams/avr35.sh: Same.
* emulparams/avr4.sh: Same.
* emulparams/avr5.sh: Same.
* emulparams/avr51.sh: Same.
* emulparams/avr6.sh: Same.
* emulparams/avrxmega1.sh: Same.
* emulparams/avrxmega2.sh: Same.
* emulparams/avrxmega3.sh: Same.
* emulparams/avrxmega4.sh: Same.
* emulparams/avrxmega5.sh: Same.
* emulparams/avrxmega6.sh: Same.
* emulparams/avrxmega7.sh: Same.
* scripttempl/avr.sc (__EEPROM_REGION_LENGTH__): Only define
if EEPROM_LENGTH is set.
(MEMORY) [eeprom]: Same.
(SECTIONS) [.eeprom]: Same for output section.
(__USER_SIGNATURE_REGION_LENGTH__): Only define if
USER_SIGNATURE_LENGTH is set.
(MEMORY) [user_signatures]: Same.
(SECTIONS) [.fuse]: Only define output section if FUSE_NAME = fuse.
(SECTIONS) [.config]: Only define output section if FUSE_NAME = config.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21569] [avr] Make avr.sc so generic that there is no need for avrtiny.sc.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

Summary|[avr] Make avr-sc so|[avr] Make avr.sc so
   |generic that there is no|generic that there is no
   |need for avrtiny.sc.|need for avrtiny.sc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21569] [avr] Make avr-sc so generic that there is no need for avrtiny.sc.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P2  |P3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21569] New: [avr] Make avr-sc so generic that there is no need for avrtiny.sc.

[gjl at gcc dot gnu.org]

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

Bug ID: 21569
   Summary: [avr] Make avr-sc so generic that there is no need for
avrtiny.sc.
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Currently, we have 2 script templates for avr.  As proposed by Nick, these
files should be unified in such a way that one script template is sufficient.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21472] [avr] Add new emulation for ATtiny416 et al.

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 10041
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10041=edit
binutils-avrxmega3.diff: Proposed patch

ld/
Upgrade the currently unused emulation avrxmega3 to one which
supports avrxmega2 devices with flash memory visible in the
SRAM address range.

PR21472
* scripttempl/avr_rodata.sc: New file.
* emulparams/avrxmega3.sh (SCRIPT_NAME): Use avr_rodata.
(RODATA_PM_OFFSET): Set to 0x8000.

gas/
PR21472
* config/tc-avr.c (mcu_types): Add entries for: attiny416,
attiny417, attiny816, attiny817.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21472] [avr] Add new emulation for ATtiny416 et al.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P2  |P3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/21472] New: [avr] Add new emulation for ATtiny416 et al.

[gjl at gcc dot gnu.org]

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

Bug ID: 21472
   Summary: [avr] Add new emulation for ATtiny416 et al.
   Product: binutils
   Version: 2.29 (HEAD)
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

WHilst the ISA of AVR ATtiny416 / 417 / 816 / 817 would fit avrxmega2, these
sevices feature the flash being accessible via the SRAM address range and
instructions.  This means that .rodata need not to be part of .data which is
the case for all other AVR devices (except avrtiny).

Using SRAM addresses for .rodata requires that such SRAM addresses are offset
by 0x8000 compared to the flash addresses as accessible by LPM, for example
like so:

__RODATA_PM_OFFSET__ = DEFINED(__RODATA_PM_OFFSET__) ? __RODATA_PM_OFFSET__ :
0x8000;


  .text   :
  {
 ...   
  }  > text
  .rodata ADDR(.text) + SIZEOF (.text) + __RODATA_PM_OFFSET__ :
  {
*(.rodata)
*(.rodata*)
*(.gnu.linkonce.r*)
  } AT> text
  .data :
  {
 ...

Consequently, we want a new emulation to support that feature in an optimal
way.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20849] [avr][avr_tiny] Don't put .rodata in RAM.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |2.28

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/21404] [avr] assertion fail in bfd/elf32-avr.c:2145

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
...and here is a direct ld call triggering the PR:

$ avr-ld bernd.elf.ltrans0.o -mavr5 --relax --defsym __tablejump2__=0
avr-ld: BFD (GNU Binutils) 2.28.51.20170321 assertion fail
../../../source/binutils-master/bfd/elf32-avr.c:2145

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/21404] [avr] assertion fail in bfd/elf32-avr.c:2145

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
Created attachment 1
  --> https://sourceware.org/bugzilla/attachment.cgi?id=1=edit
bernd.elf.ltrans0.o

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/21404] [avr] assertion fail in bfd/elf32-avr.c:2145

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org,
   ||saaadhu at gcc dot gnu.org

--- Comment #1 from Georg-Johann Lay  ---
Hi Sentil, CC'ing you as you might have some clue about this assertion failure.

A more verbose output with -v:

$ avr-gcc bernd.elf.ltrans0.s -mmcu=atmega168 -mrelax -v
Using built-in specs.
Reading specs from
/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/device-specs/specs-atmega168
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/srv/local/gnu/install/gcc-6/bin/../libexec/gcc/avr/6.3.1/lto-wrapper
Target: avr
Configured with: ../../gcc.gnu.org/gcc-6-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-6 --disable-nls --disable-shared --with-dwarf2
--with-gnu-ld --with-gnu-as --enable-languages=c,c++ --enable-checking=release
: (reconfigured) ../../gcc.gnu.org/gcc-6-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-6 --disable-nls --disable-shared --with-dwarf2
--with-gnu-ld --with-gnu-as --enable-checking=release target_alias=avr
--enable-languages=c,c++,lto --no-create --no-recursion
Thread model: single
gcc version 6.3.1 20170418 [gcc-6-branch revision 243886] (GCC) 
COLLECT_GCC_OPTIONS= '-mrelax' '-v' '-specs=device-specs/specs-atmega168'
'-mmcu=avr5'
 /srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/bin/as
-v -mmcu=avr5 --mlink-relax -mno-skip-bug -o /tmp/ccXAfFYs.o
bernd.elf.ltrans0.s
GNU assembler version 2.28.51 (avr) using BFD version (GNU Binutils)
2.28.51.20170321
COMPILER_PATH=/srv/local/gnu/install/gcc-6/bin/../libexec/gcc/avr/6.3.1/:/srv/local/gnu/install/gcc-6/bin/../libexec/gcc/:/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/bin/
LIBRARY_PATH=/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/avr5/:/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/lib/avr5/:/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/:/srv/local/gnu/install/gcc-6/bin/../lib/gcc/:/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/lib/
COLLECT_GCC_OPTIONS= '-mrelax' '-v' '-specs=device-specs/specs-atmega168'
'-mmcu=avr5'
 /srv/local/gnu/install/gcc-6/bin/../libexec/gcc/avr/6.3.1/collect2 -plugin
/srv/local/gnu/install/gcc-6/bin/../libexec/gcc/avr/6.3.1/liblto_plugin.so
-plugin-opt=/srv/local/gnu/install/gcc-6/bin/../libexec/gcc/avr/6.3.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccLCJimU.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-latmega168 -mavr5 -Tdata 0x800100 --relax
/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/lib/avr5/crtatmega168.o
-L/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/avr5
-L/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/lib/avr5
-L/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1
-L/srv/local/gnu/install/gcc-6/bin/../lib/gcc
-L/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/lib
/tmp/ccXAfFYs.o --start-group -lgcc -lm -lc -latmega168 --end-group
/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/bin/ld:
BFD (GNU Binutils) 2.28.51.20170321 assertion fail
../../../source/binutils-master/bfd/elf32-avr.c:2145
collect2: error: ld returned 1 exit status

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/21404] New: [avr] assertion fail in bfd/elf32-avr.c:2145

[gjl at gcc dot gnu.org]

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

Bug ID: 21404
   Summary: [avr] assertion fail in bfd/elf32-avr.c:2145
   Product: binutils
   Version: 2.28
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---
Target: avr

Created attachment 
  --> https://sourceware.org/bugzilla/attachment.cgi?id==edit
bernd.elf.ltrans0.s

$ avr-gcc bernd.elf.ltrans0.s -mmcu=atmega168 -mrelax 

/srv/local/gnu/install/gcc-6/bin/../lib/gcc/avr/6.3.1/../../../../avr/bin/ld:
BFD (GNU Binutils) 2.28.51.20170321 assertion fail
../../../source/binutils-master/bfd/elf32-avr.c:2145
collect2: error: ld returned 1 exit status

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20849] [avr][avr_tiny] Don't put .rodata in RAM.

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  ---
Mnay thanks for taking care of this!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20849] [avr][avr_tiny] Don't put .rodata in RAM.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P2  |P3

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20849] [avr][avr_tiny] Don't put .rodata in RAM.

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 9658
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9658=edit
Untested patch

ld/
PR target/20849
* scripttempl/avrtiny.sc (__RODATA_PM_OFFSET__): New define.
(.rodata): New section.
(.data): Remove .rodata*.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/20849] New: [avr][avr_tiny] Don't put .rodata in RAM.

[gjl at gcc dot gnu.org]

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

Bug ID: 20849
   Summary: [avr][avr_tiny] Don't put .rodata in RAM.
   Product: binutils
   Version: 2.27
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

The current linker description files for AVR_TINY like avrtiny.x et al are
locating .rodata into SRAM which is quite a waste for devices with up to 128
Bytes of SRAM.

As flash is accessible by LD instructions which read from RAM (provided an
offset of 0x4000 is added), a better approach is just to add 0x4000 to the VMA
of .rodata objects.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/15043] [avr] Support new command line options -mdes and -matomics

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME
   Target Milestone|--- |2.25

--- Comment #1 from Georg-Johann Lay  ---
Meanwhile, there is -mrmw to support read-modify-write (LAS, LAC, LAT and XCH)
instructions since 2.25:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d24e46e3e247e46eb2f5e7ebb5efd0f9fcc5fcdd

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/18269] avr-binutils fail to build

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||senthil.thecoder at gmail dot 
com

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/18269] New: avr-binutils fail to build

[gjl at gcc dot gnu.org]

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



Bug ID: 18269

   Summary: avr-binutils fail to build

   Product: binutils

   Version: 2.26 (HEAD)

Status: NEW

  Severity: normal

  Priority: P2

 Component: binutils

  Assignee: unassigned at sourceware dot org

  Reporter: gjl at gcc dot gnu.org



The current avr-Binutils fail to build because of a build warning which

actually rises an erreor.



This blocks the build robot from producing usable results, c.f. the results
 for

avr at http://toolchain.lug-owl.de/buildbot/#job436509



binutils configures as



./../source/binutils-master/configure --target=avr

--prefix=/local/gnu/install/gcc-5.0 --disable-nls



Build message:



gcc -DHAVE_CONFIG_H -I. -I../../../source/binutils-master/gas  -I.

-I../../../source/binutils-master/gas -I../bfd

-I../../../source/binutils-master/gas/config

-I../../../source/binutils-master/gas/../include

-I../../../source/binutils-master/gas/..

-I../../../source/binutils-master/gas/../bfd

-DLOCALEDIR=\/local/gnu/install/gcc-5.0/share/locale\  -W -Wall

-Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror

-I../../../source/binutils-master/gas/../zlib -g -O2 -MT tc-avr.o -MD -MP -
MF

.deps/tc-avr.Tpo -c -o tc-avr.o `test -f 'config/tc-avr.c' || echo

'../../../source/binutils-master/gas/'`config/tc-avr.c

../../../source/binutils-master/gas/config/tc-avr.c: In function

‘create_record_for_frag’:

../../../source/binutils-master/gas/config/tc-avr.c:2063:36: error: declara
tion

of ‘link’ shadows a global declaration [-Werror=shadow]

cc1: all warnings being treated as errors

make[4]: *** [tc-avr.o] Error 1

make[4]: Leaving directory `/local/gnu/build/binutils-master-avr/gas'

make[3]: *** [all-recursive] Error 1

make[3]: Leaving directory `/local/gnu/build/binutils-master-avr/gas'

make[2]: *** [all] Error 2

make[2]: Leaving directory `/local/gnu/build/binutils-master-avr/gas'

make[1]: *** [all-gas] Error 2

make[1]: Leaving directory `/local/gnu/build/binutils-master-avr'

make: *** [all] Error 2



-- 

You are receiving this mail because:

You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/18269] avr-binutils fail to build

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Target||avr

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/17107] AVR Linker Scripts missing gnu.linkonce sections

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Target||avr
   Priority|P2  |P3
 CC||senthil.thecoder at gmail dot 
com

--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org ---
Following sections are missing from the avr linker scripts:

For .text:

.gnu.linkonce.t
.gnu.linkonce.t.*

For .rodata (part of .data):

.gnu.linkonce.r
.gnu.linkonce.r.*

For .bss:

.gnu.linkonce.b
.gnu.linkonce.b.*

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/16005] [avr] Linker crash on a particular instruction sequence with --relax

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Target||avr
 CC||gjl at gcc dot gnu.org

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/16005] [avr] Linker crash on a particular instruction sequence with --relax

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=16005

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

Version|unspecified |2.23

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

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/15043] New: [avr] Support new command line options -mdes and -matomics

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=15043

 Bug #: 15043
   Summary: [avr] Support new command line options -mdes and
-matomics
   Product: binutils
   Version: 2.24 (HEAD)
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: gas
AssignedTo: unassig...@sourceware.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Classification: Unclassified
Target: avr


The avr tools currently support around 200 devices and there are more,
unsupported devices.

It makes hardly any sense to add a -mmcu=device switch for each and every
target:  For binutils, it's enough to know the instruction set architecture
(ISA) to assemble for.

Thus, command line switches like -mdes and -matomic could greatly reduce the
time until new devices are supported, because the compiler need not to wait
until respective support in binutils is available:

The compiler could just call avr-as with -mmcu=core -mdes if it knows that the
device supports the DES instruction and with -mmcu=core -mno-des, otherwise.

The options shall work as follows:

With -mdes, the assembler will accept and assemble the DES instruction.
With -mno-des, the assembler will issue an unknown instruction error.

If a device is specified with -mmcu= then the assembler knows the right setting
for -m[no-]des and uses it, provided it is not explicitly overridden by
-m[no-]des. Alternatively, -m[no-]des could be ignored in that case.

If a core like avr4 definitely does not support DES instruction, the option is
ignored and the behavior the same as it would be with -mno-des.

Similar for -m[no-]atomics and the instructions XCH, LAC, LAS, LAT.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14406] New: Support .progmemN.data sections to work with GCC's PR49868

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14406

 Bug #: 14406
   Summary: Support .progmemN.data sections to work with GCC's
PR49868
   Product: binutils
   Version: 2.23 (HEAD)
   URL: http://gcc.gnu.org/PR49868
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Classification: Unclassified
Target: avr


GCC's named address spaces like __flash1 will locate data to input section
.progmem.data1, see section Limitations and Caveats in

http://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html 

The default linker script should support these sections so
that programmers can use the new address spaces and their
default sections without writing their own linker script files
that define .progmemN.data

Moreover, the default linker script should change
  *(.progmem*)
to
  *(.progmem)
  *(.progmem.*)

If .text overlaps with .progmem1 and .progmem1 in non-empty,
the linker should stop with an error.

If .progmem1 is empty, everything is fine.

Similar for all the other .progmemN sections and combinations.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14406] Support .progmemN.data sections to work with GCC's PR49868

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14406

--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-07-26 
11:02:15 UTC ---
(In reply to comment #0)

 .progmem.data1

.progmem1.data

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/14255] New: Internal error, aborting at ./gas/symbols.c line 96 in symbol_new

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14255

 Bug #: 14255
   Summary: Internal error, aborting at ./gas/symbols.c line 96 in
symbol_new
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
AssignedTo: unassig...@sourceware.org
ReportedBy: g...@gcc.gnu.org
Classification: Unclassified
  Host: mingw32
 Build: x86-linux-gnu


Created attachment 6450
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6450
bug-as.sx Assembler source

bug-as.sx: Assembler messages:
bug-as.sx: Internal error, aborting at ./gas/symbols.c line 96 in symbol_new
Please report this bug.

The attached test case bug-as.sx uses an undefined local label in line 28:

 brne 4f

Maybe that is the root cause?


== Versions == 

Seen with HEAD from 2012-06-06 and with binutils-2.21
Not yet tested with a native binutils, I have only canadians available at the
moment.


== command line ==

avr-as bug-as.sx -mmcu=avr5


== configure ==

--target=avr --disable-nls --host=i386-mingw32 --build=i686-linux-gnu

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-06-07 
18:00:55 UTC ---
Fixed

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[avr ] Wrong symbol values  |[avr] Wrong symbol values
   |with --gc-sections  |with --gc-sections

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

--- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-23 
19:36:45 UTC ---
Created attachment 6417
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6417
Tentative patch: Keep .data

This is a tentative patch to fix the issue by KEEPing .data.

Lightly tested with a small program.

Johann

ld/
PR 13697
* scripttempl/avr.sc (.data): Keep it.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14058] Internal overflow error, on 128kB FLASH with no relaxation

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14058

--- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-04 
13:42:39 UTC ---
(In reply to comment #6)

 The original bug report IMO contained everything needed to reproduce the bug
 and to assess it as different from the trampolines high case, without the
 need to read the avrfreaks.net thread.

 [...]
 
 Moreover, I also believe that absolute placement of labels through .org
 (however deprecated it is for real life usage) is more illustrative of the
 underlying reason than your .space solution. Also the usage of --debug-stubs
 switch is not coincidental.

The reduced example from comment #4 removes external dependencies like

* avr-gcc
* crtmxxx.o from AVR-LibC
* Command options passed like -Tdata=

Please note that GCC and AVR-LibC are not part of binutils, so that I worked
out an example without these external dependencies.

Also note that /we/ want something from the binutils developers (I am not one
of them), in particular to fix problems. They do not want something from /us/.
It's us who need their help, knowledge, experience, time and pacience.

To help the developes fix a problem, we should not use external stuff, just as
an #include avr/io.h or #include lcd.h might deter a GCC developer from
tracking an avr-gcc issue. We should always strive to have no external
dependencies or references and self-contained and comprehensible reports.

For a binutils developer, the difference between two targets is just to switch
from --target=foo to --target=bar. Many stuff in binutils is /not/ AVR-related,
so we basically exclude all developers that would help with avr-binutils
problems that are not familiar with avr-gcc or want to install MS-windows
distributions or build AVR-Libc. I just stripped external stuff in order to
/not/ exclude any binutils developers.

As I played with the test case, I used .space just because I don't know the
semantics of .org; in particular you linked against crt so that the very code
startes after 0x100 and then there was an .org 0x100 in the code. So no drama
here.

Concerning the relatedness to PR13812 it might very well be the case that I am
plain wrong with my conclusions/analysis from there. It might be just as well
be the case that it's completely unrelated to shifting stubs out of segment
and instead is caused by using gs() targeting different segments as from this
PR.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13812] Suboptimal default linker script cause internal error: out of range error

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13812

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||konfera at efton dot sk

--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-03 
20:13:06 UTC ---
*** Bug 14058 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14058] Internal overflow error, on 128kB FLASH with no relaxation

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14058

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-03 
20:13:06 UTC ---
See the comments in PR13812

If you use such big programs, .trampolines gets shifted out of it's 128KiB
section.

Notice that the code will malfunction then because the assumption is that
.trampolines is located in the 128 KiB segment where EIND points to; at least
that is the assumption of GCC which you are obviously using.

Moreover, the actual position or .trampolines must not be messed up by code or
linker script by shifting it out of place.

The default linker scripts are just a default; it won't and cannot any setup
imagineable. If you need special arrangement for you code, you may want to
arrange code and data according to your needs.

The inconvenience could be reduced by a more descriptive error message, yes,
and the default ld script be arranged to suit better this situation. But then
other issues might pop up more frequently like shifting .low_text or .progmem
out of place.

For some explanation on linker stubs and gs(), see also

3.17.3.1 EIND and Devices with more than 128 Ki Bytes of Flash

http://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

*** This bug has been marked as a duplicate of bug 13812 ***

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14058] Internal overflow error, on 128kB FLASH with no relaxation

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14058

--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-03 
21:57:19 UTC ---
(In reply to comment #2)

 Please re-read [...] the post at the given link.

Please make bug reports that are self-contained.

If there is information missing to reproduce the issue or to understand it,
please add the information to render the bug report self-contained.

If the PR is already self-contained and includes all information, a link is
simply distracting and confusing and superfluous.

Thanks.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/14058] Internal overflow error, on 128kB FLASH with no relaxation

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=14058

--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-05-03 
22:03:18 UTC ---
Here is a reduced example:

; == foo.ss ==
.text

K1:  nop

.space 0x1fff6

K2:  nop

.section .progmem, a, @progbits
.word gs(K1)
.word gs(K2)

== Assemble ==

$ avr-as -mmcu=avr6 foo.ss -o foo.o

== Link ==

$ avr-ld -m avr6 foo.o -o foo.elf -Map=foo.map

With .space 0x1fff4 the linker passes.

Is using linker stubs supported without --relax at all?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13899] [avr]: Wrong relaxation of R_AVR_16_PM with gs()

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13899

--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-04-28 
12:33:28 UTC ---
(In reply to comment #2)
 
 Disassembly of section .text:
 
  menuitem_uhr:
0:0a 00 [...]
 
 000e onPixel_uhr:
 
 The first entry of menuitem_uhr is 0x000a. The correct value 
 is 0x0007 = 0xe / 2, i.e. the word address of menuitem_uhr.
___^^^

The word address of onPixel_uhr, of course.



Note: The testcase can be simplified even more to:

.text
call onPixel_uhr
onPixel_uhr:
nop
.section .progmem.data,a,@progbits
.type menuitem_uhr, @object
menuitem_uhr:
.word gs(onPixel_uhr)

And then assembled/linked/dumped

$ avr-as -mmcu=atmega168 uhr.s -o uhr.o
$ avr-ld -o bug13899.elf -m avr5 --relax uhr.o
$ avr-objdump -d bug13899.elf

Disassembly of section .text:

 menuitem_uhr:
   0:03 00   ..

0002 __ctors_end:
   2:00 d0   rcall.+0  ; 0x4 onPixel_uhr

0004 onPixel_uhr:
...

The word address of onPixel_uhr is 0x0002, but menuitem_uhr recorded 0x0003.

The error also occurs if menuitem_uhr is located in .data instead of in section
.progmem.data

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13899] [avr]: Wrong relaxation of R_AVR_16_PM with gs()

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13899

--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-04-27 
23:50:14 UTC ---
Created attachment 6379
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6379
uhr.s

Here is a condensed test case.

The first entry of menuitem_uhr shall contain the word address of onPixel_uhr:

.globalmenuitem_uhr
.section.progmem.data,a,@progbits
.typemenuitem_uhr, @object
menuitem_uhr:
.wordgs(onPixel_uhr)

But avr-ld generates a wrong entry 0x000a instead of the correct 0x0007.

With the attached assembler file, perform

$ avr-as -mmcu=atmega168 uhr.s -o uhr.o
$ avr-ld -o bug13899.elf -m avr5 -Tdata 0x800100 --relax -defsym morse=0 -v
uhr.o
$ avr-objdump -h -S -j .data -j .text bug13899.elf


The output is:

GNU ld (GNU Binutils) 2.22.52.20120322

bug13899.elf: file format elf32-avr

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 0016      0054  2**1
  CONTENTS, ALLOC, LOAD, READONLY, CODE

Disassembly of section .text:

 menuitem_uhr:
   0:0a 00 06 00 04 00 04 00 

0008 __ctors_end:
   8:fb df   rcall.-10 ; 0x0 menuitem_uhr

000a onRedraw_uhr:
   a:fa df   rcall.-12 ; 0x0 menuitem_uhr
   c:f9 df   rcall.-14 ; 0x0 menuitem_uhr

000e onPixel_uhr:
   e:f8 df   rcall.-16 ; 0x0 menuitem_uhr
  10:f7 df   rcall.-18 ; 0x0 menuitem_uhr
  12:f6 df   rcall.-20 ; 0x0 menuitem_uhr
  14:f5 df   rcall.-22 ; 0x0 menuitem_uhr

The first entry of menuitem_uhr is 0x000a.
The correct value is 0x0007 = 0xe / 2, i.e. the word address of menuitem_uhr.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13899] [avr]: Wrong relaxation of R_AVR_16_PM with gs()

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13899

--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-28 
11:51:22 UTC ---
Notes

If you work on linux, you will want to

$ dos2unix good.lst

in order to change newlines to unix style.

And in the Makefile, diff results get smaller if objdump gets called with -d
instead of with -S like so:

exe:
$(LD) -o $(EXE).elf --relax $(OBJ) -L. -lgcc -lc -lgcc 
$(OBJDUMP) -z -h -d -j .data -j .text $(EXE).elf  $(EXE).lst

_^^ -d instead of -S

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13899] New: [avr]: Wrong relaxation of R_AVR_16_PM with gs()

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13899

 Bug #: 13899
   Summary: [avr]: Wrong relaxation of R_AVR_16_PM with gs()
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Classification: Unclassified
Target: avr


Created attachment 6301
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6301
bug-relax.zip: Files to reproduce

The linker computes wrong values for gs() initializers like from text.s:

.globalmenuitem_text
.section.progmem.data,a,@progbits
.typemenuitem_text, @object
.sizemenuitem_text, 14
menuitem_text:
.wordgs(onPixel_text)
.wordgs(onRedraw_text)
.wordgs(onKey_text)
.wordgs(onEnter_text)

I tried to work out a small example, but with no avail.
So I post the whole project.

Steps to reproduce:

1) Unpack the attached zip file. It inflates to ./bug-relax/

2) cd ./bug-relax

3) There are assembler sources in the directory and a small Makefile. Run
   make obj all

4) This generates two files bug.elf and bug.lst
   bug.lst is diff'ed against good.lst generated with avr-ld 2.21

All in all, the make obj all will print something like

avr-as -mmcu=atmega168 frac8.ss -o frac8-asm.o
avr-as -mmcu=atmega168 parith-16.ss -o parith-16-asm.o
...
avr-ld -m avr5 -Tdata 0x800100 crtm168.o -v -o bug.elf --relax ...
GNU ld (GNU Binutils) 2.22.52.20120322

diff -u1 good.lst bug.lst

-good.elf: file format elf32-avr
+bug.elf: file format elf32-avr

@@ -81,3 +81,3 @@
 008e menuitem_text:
-  8e:78 06 23 06 af 05 18 06 19 01 28 04 4f 01
+  8e:7c 06 24 06 af 05 18 06 19 01 28 04 4f 01

@@ -163,3 +163,3 @@
 0299 menuitem_asteroids:
- 299:61 0c 6a 0d 1a 0b de 0a 8f 02 08 02 e8 02
+ 299:70 0c 7f 0d 1b 0b de 0a 8f 02 08 02 e8 02

@@ -217,3 +217,3 @@
 03ae menuitem_snake:
- 3ae:92 11 7d 10 24 0f 58 0f 6d 03 52 02 bc 03
+ 3ae:92 11 7f 10 24 0f 58 0f 6d 03 52 02 bc 03

@@ -263,3 +263,3 @@
 0491 menuitem_schoner:
- 491:9a 14 e3 13 18 14 09 14 02 01 00 08 9f 04
+ 491:9b 14 e3 13 18 14 09 14 02 01 00 08 9f 04


In text.s: menuitem_text the first enty is
   .wordgs(onPixel_text)

This function is located at word address 0x0678:
   0cf0 onPixel_text

But bug.lst has 0x67c as printed in the diff above.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13812] New: Suboptimal default linker script cause internal error: out of range error

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13812

 Bug #: 13812
   Summary: Suboptimal default linker script cause internal
error: out of range error
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Classification: Unclassified
Target: avr


On big devices where stubs are generated to reach all targets of indirect
jumps, the following error might occur:

 warning: internal error: out of range error

Reason is the following part of the default linker script that
places .trampolines after .progmem:

/* For data that needs to reside in the lower 64k of progmem.  */
*(.progmem.gcc*)
*(.progmem*)
. = ALIGN(2);
 __trampolines_start = . ;
/* The jump trampolines for the 16-bit limited relocs will reside here.  */
*(.trampolines)
*(.trampolines*)
 __trampolines_end = . ;

Thus, if there is lot of data in the .progmem.data section (which is avr-gcc's
default section for data located in flash), the .trampolines section is located
outside the first 64 Ki word segment.

There are two issues:

1) The error message is not helpful at all. It should mention that something
   goes wrong with the .trampolines or gs() modifiers or stubs generation.

2) The error could be avoided by placing .trampolines prior to .progmem like
so:

/* For data that needs to reside in the lower 64k of progmem.  */
*(.progmem.gcc*)
. = ALIGN(2);
 __trampolines_start = . ;
/* The jump trampolines for the 16-bit limited relocs will reside here.  */
*(.trampolines)
*(.trampolines*)
 __trampolines_end = . ;
*(.progmem*)

The .progmem.gcc* section is used for jump dispatch tables (e.g.
.progmem.gcc_sw_table) and must be located in lower 64 KiB

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13812] Suboptimal default linker script cause internal error: out of range error

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13812

--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-05 
21:36:52 UTC ---
Created attachment 6262
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6262
stubc.c: Simplified C test case

Compile with

avr-gcc -mmcu=atmega2560 stubs.c -S -Os

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13812] Suboptimal default linker script cause internal error: out of range error

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13812

--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-05 
21:48:30 UTC ---
Created attachment 6263
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6263
stubc.s: Assembler file

Assemble/Link with:

avr-as -mmcu=atmega2560 stubs.s -o stubs.o
avr-ld -mavr6 stubs.o

or at your option

avr-gcc -mmcu=atmega2560 stubs.s

Error message:

stubs.o: In function `main':
stubs.c:(.text.startup+0x0): warning: internal error: out of range error
stubs.c:(.text.startup+0x2): warning: internal error: out of range error

Relevant part of the map file:

.text   0x0x2720e
 *(.vectors)
 .vectors   0x   0xe4
e:/winavr/4.7.0-3/bin/../lib/gcc/avr/4.7.0/../../../../avr/lib/avr6/crtm2560.o
0x__vector_default
0x__vectors
 *(.vectors)
 *(.progmem.gcc*)
 *(.progmem*)
 .progmem.data  0x00e40x27100 stubs.o
0x00e4array4
0x7de4array3
0xfae4array2
0x000177e4array1
0x0001f4e4array0
0x000271e4. = ALIGN (0x2)
0x000271e4__trampolines_start = .
 *(.trampolines)
 .trampolines   0x000271e40x4 linker stubs
 *(.trampolines*)
0x000271e8__trampolines_end = .
 *(.jumptables)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/13503] [avr] Support RELOCs to represent a byte

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13503

--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-04 
13:39:16 UTC ---
(In reply to comment #1)
 See also respective extensions to avr-gcc:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50931

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/13503] [avr] Support RELOCs to represent a byte

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13503

--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-04 
13:41:53 UTC ---
(In reply to comment #1)
 See also respective extensions to avr-gcc:

Finally, the right link to the avr-gcc named address space support, including
24-bit pointers:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49868

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/12742] ld error unrecognized option '-plugin' on mingw and how to build with plugins enabled on mingw

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12742

--- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-01 
21:29:25 UTC ---
Tried again today and I can do a Canadian cross build and LTO works :-))

Configuration was 

Build  = i686-pc-linux-gnu
Host   = i386-pc-mingw32
Target = avr-unknown-none

With GCC 3.4.5 as linux - mingw32 cross
and GCC from trunk with 50616 fixed.

Binutils were from trunk but some days/weeks old.
There was no fake libdl or dlfcn-win32 in the build environment.

The last problem I had was that the linker calls the plugin but failed to
operate properly on it; presumably unloading the dll but I don't know enough of
that stuff.

Anyways, now it works and a small LTO compile finished without error and
produced reasonable results and optimizations that only LTO can perform. Great!

Hope I will find the time to bundle the snapshot build so that more people can
test and experiment with it and report problems.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/12742] ld error unrecognized option '-plugin' on mingw and how to build with plugins enabled on mingw

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12742

--- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-21 
22:46:45 UTC ---
Thanks for the patch, I can test after GCC's http://gcc.gnu.org/PR50616 is
fixed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/12742] ld error unrecognized option '-plugin' on mingw and how to build with plugins enabled on mingw

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12742

--- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-21 
22:48:36 UTC ---
Something strange happened to the link. Again GCC's PR:
http://gcc.gnu.org/PR50616

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/12742] ld error unrecognized option '-plugin' on mingw and how to build with plugins enabled on mingw

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12742

--- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-21 
22:49:50 UTC ---
Ok, there is some PR magic. GCC PR number is 50616.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] New: [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

 Bug #: 13697
   Summary: [avr ] Wrong symbol values with --gc-sections
   Product: binutils
   Version: 2.23 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: g...@gcc.gnu.org
Classification: Unclassified


Suppose the following small C program:

int main (void)
{
extern char __heap_start;
return (int)  __heap_start;
}

Compile with:

avr-gcc heap-start.c -mmcu=atmega168 -o heal-start.elf -Os -save-temps
-Wl,-Map,heap-start.map -Wl,--gc-sections

Assembler output is:


.fileheap-start.c
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
.section.text.startup,ax,@progbits
.globalmain
.typemain, @function
main:
.L__stack_usage = 0
ldi r24,lo8(__heap_start)
ldi r25,hi8(__heap_start)
ret
.sizemain, .-main
.identGCC: (GNU) 4.7.0 20120206 (experimental)


ATmega168 has RAM start at 0x100 but the generated map file reads

...
 *(.data)
 *(.data*)
 *(.rodata)
 *(.rodata*)
 *(.gnu.linkonce.d*)
0x00800100. = ALIGN (0x2)
0x00800100_edata = .
0x00800100PROVIDE (__data_end, .)

.bss0x008000600x0
0x00800060PROVIDE (__bss_start, .)
 *(.bss)
 *(.bss*)
 *(COMMON)
0x00800060PROVIDE (__bss_end, .)
0x008a__data_load_start = LOADADDR (.data)
0x008a__data_load_end = (__data_load_start
+ SIZEOF (.data))

.noinit 0x008000600x0
0x00800060PROVIDE (__noinit_start, .)
 *(.noinit*)
0x00800060PROVIDE (__noinit_end, .)
0x00800060_end = .
0x00800060PROVIDE (__heap_start, .)
...

That is obviously wrong because .bss starts at RAM 0x60.

Notice that the program does not define data in the static storage.
If data in static storage is added or --gc-sectons is removed, the values are
as expected.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Target||avr
 CC||eric.weddington at atmel
   ||dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 
10:21:47 UTC ---
Created attachment 6217
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6217
heap-start.s

avr-gcc's assembler output

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 
10:26:29 UTC ---
Created attachment 6219
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6219
Console Output with -v -Wl,-v

Console output for the following command:

avr-gcc heap-start.c -mmcu=atmega168 -o heal-start.elf -Os -save-temps
-Wl,-Map,heap-start.map -Wl,--gc-sections -v -Wl,-v

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 
10:22:58 UTC ---
Created attachment 6218
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6218
heap-start.map

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 
10:32:07 UTC ---
Created attachment 6220
  -- http://sourceware.org/bugzilla/attachment.cgi?id=6220
heal-start.elf: Disassembly from avr-objdump -d

avr-objdump -d heal-start.elf | grep -A 3 'main:'

0080 main:
  80:   80 e6   ldi r24, 0x60   ; 96
  82:   90 e0   ldi r25, 0x00   ; 0
  84:   08 95   ret

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||childbear0 at gmail dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13697] [avr ] Wrong symbol values with --gc-sections

[gjl at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13697

--- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-02-16 
12:30:29 UTC ---
(In reply to comment #5)
 I think this pain is self-inflicted.
 
 You're using -m avr5 -Tdata 0x800100 instead of -m avr51.  So you get the avr5
 ld script with the data section fudged to be at 0x800100.  However, the data
 section is stripped by -gc-sections.  So the address change doesn't affect
 following sections.  They stay at the avr5 data memory region of 0x800060.

atmega168 is element of avr5 and not element of avr51 (avr51 has ELPM
instruction for example. ATmega168 has no ELPM).

avr-gcc mixes devices with different RAM-start in the same core architecture,
see mcu-devices.def:

http://gcc.gnu.org/viewcvs/trunk/gcc/config/avr/avr-mcus.def?revision=184276content-type=text%2Fplainview=co

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils