Re: [avr-libc-dev] .bss section unitialized

[Marian Buschsieweke]

Dear avr-libc developers,

I was just pointed out that, unlike for ARM targets, the RIOT build system does
not check for overflow of RAM and ROM. Manual checking confirms that I'm using
8443B out of 8192B :-(

Sorry for disturbing with a stupid question.

Kind regards,
Marian

-------------------------------------------------------------
M.Sc. Marian Buschsieweke
Dept. Communication and Networked Systems (ComSys)
Institute for Intelligent Cooperating Systems (IKS)
Otto-von-Guericke-University of Magdeburg
Universitätsplatz 2, Building 29, Room 314
39106 Magdeburg
Germany

http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html
Tel.: +49 - 391 - 67 - 52673
Fax:  +49 - 391 - 67 - 41161

-------------------------------------------------------------

On Mon, 23 Jul 2018 21:11:19 +0200
Marian Buschsieweke <address@hidden> wrote:

> Dear avr-libc developers,
> 
> tl;dr: Does anyone know what could be the problem when the .bss section is
> uninitialized?
> 
> I'm trying to build RIOT [1] using avr-libc 2.0.0 and GCC 6.4.0 for the
> Arduino UNO (ATmega328p) and the Arduino Mega2560 (ATmega2560), but I ran 
> into a
> bunch of strange bugs. Upon investigation with AVaRICE and an AVR Dragon it
> seems that the .bss section (or at least part of it) remains uninitialized, as
> at least the variables I investigated on contained random values before they
> were first used.
> 
> I have to admit that I have trouble to get AVaRICE working reliable. (E.g.
> setting breakpoints through gdb doesn't seem to work for me, but inline
> assembly using `asm("break");` statements seem to work reliable for me.) So
> maybe the problem is completely different and reading random values is caused
> by my fragile AVaRICE setup... At least when reading the same variable 
> multiple
> times without rebooting the Arduino I consistently get the same value, which
> gives me some confidence in the results.
> 
> How to reproduce:
> - Clone git://github.com/RIOT-OS/RIOT
> - cd into examples/default
> - Add the following lines to the Makefile after assignment of the
>   BOARD_PROVIDES_NETIF variable:
> 
> CFLAGS += -std=gnu99 # <-- Only required if asm("break"); is used
> BOARD_PROVIDES_NETIF += arduino-mega2560
> USEMODULE += w5100
> CFLAGS += -DW5100_PARAM_CS=ARDUINO_PIN_10
> CFLAGS += -DW5100_PARAM_EVT=ARDUINO_PIN_2
> 
>  - Run "make BOARD=arduino-mega2560"
>  - Add a breakpoint in file sys/net/gnrc/pktbuf_static/gnrc_pktbuf_static.c in
>    line 84 before `mutex_lock(&_mutex);` in function
>    `void gnrc_pktbuf_init(void)`.
>     - You could insert `asm("break");` into the code (and run
>       make BOARD=arduino-mega2560 again)
>  - Investigate the contents of _mutex. It contains a random value, even though
>    it should contain `NULL`
>  - Btw: "make BOARD=arduino-mega2560 flash" runs avrdude for you to flash the
>    board
> 
> Compiling with other toolchains (other versions of GCC or/and avr-libc) result
> in binaries that have similar issues.
> 
> Does someone know what the problem could be?
> 
> Kind regards,
> Marian
> 
> [1]: http://riot-os.org/
> 
> -------------------------------------------------------------
> M.Sc. Marian Buschsieweke
> Dept. Communication and Networked Systems (ComSys)
> Institute for Intelligent Cooperating Systems (IKS)
> Otto-von-Guericke-University of Magdeburg
> Universitätsplatz 2, Building 29, Room 314
> 39106 Magdeburg
> Germany
> 
> http://www.comsys.ovgu.de/Team/Marian+Buschsieweke.html
> Tel.: +49 - 391 - 67 - 52673
> Fax:  +49 - 391 - 67 - 41161

pgp26h2P3ZQX0.pgp
Description: OpenPGP digital signature