Weird global variable initialization behaviour

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using an attiny1634 as a dedicated crypto chip with which my main mcu interacts over SPI. I'm using the 3rd party library avrnacl for this. The problem is that the library returns the wrong results, EXCEPT when I add a dummy global variable (which is never used) which I initialize to some non-zero value. If I do this, all is well. This isn't the cleanest solution though, and I also would like to know what's going on.

Below is my main function. The while loop gets commands from the main mcu and then encrypts/decrypts whatever the main mcu asked for and sends it back. The problem is not with the SPI communication, I already checked that. It's the crypto library on the attiny that's causing the problem (except when I use the dummy variable).

 

#include <avr/io.h>
#include "crypto_protocol_slave.h"

uint8_t myvariable = 1; /* Without this the library returns garbage */

int main() {
    crypto_protocol_slave_init(); 

    while(1) {
        crypto_protocol_slave_process_packet();
    }

    return 0;
}

 I know it might be difficult to get a solution without me providing any other part of the code but this would make my post needlessly long and I feel this might be a typical noob mistake somewhere. I already made sure all variables in my code are initialized if that helps. Does anyone know what could be causing this?

Last Edited: Fri. Mar 11, 2016 - 04:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about a link to the part that actually has the problem?  ???

 

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is my wrapper for the library (crypto_secretbox from avrnacl). This returns unexpected results without my dummy variable I posted earlier.

int crypto_nacl_auth_encrypt(uint8_t *c, uint8_t *m, uint8_t mlen, uint8_t *n, uint8_t *k) {
    uint8_t m_secretbox[CRYPTO_MAX_LEN + crypto_secretbox_ZEROBYTES] = {0};
    uint8_t c_secretbox[CRYPTO_MAX_LEN + crypto_secretbox_ZEROBYTES] = {0};
    uint8_t return_value = 0;

    /* Copy m to m_secretbox with leading zeros. */
    memcpy(m_secretbox+crypto_secretbox_ZEROBYTES, m, mlen);

    /* Encrypt */
    return_value = crypto_secretbox(c_secretbox, m_secretbox, mlen+crypto_secretbox_ZEROBYTES, n, k);

    /* Copy c_secretbox to c without leading zeros */
    memcpy(c, c_secretbox+crypto_secretbox_BOXZEROBYTES, mlen+AUTH_LEN);

    return return_value;
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like something to do with _do_copy_data(). That is the function that sets up .data

 

Maybe show an Asm dump of the first 100..200 bytes of code - basically enough to include the IVT and CRT.

 

Like Kiobk I'd like to see a link to the code of this library - is it only provided as a precompiled .a or is it just more source files you add to your project and build locally?

 

I'd also like to see the complete build invocation including -fdata-sections, -gc-sections and other stuff like that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nimyz wrote:
[CRYPTO_MAX_LEN + crypto_secretbox_ZEROBYTES]

How big are these arrays?

 

How big are the "holders"? (i.e., "c", "m")  Are the lengths exactly right after the calculations?

 

[If the lengths aren't "quite right", then adding the global variable gives a place for the memcpy() to "overflow" without wreaking apparent havoc.  Also, if the arrays are say a few hundred bytes then you are straining the SRAM resources.]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I uploaded the asm dump here: http://pastebin.com/Jab1UNMz

 

The library is built locally (with the creator's makefile) and then included as .a file. You can get a copy as follows:

 

wget http://munacl.cryptojedi.org/data/avrnacl-20140813.tar.bz2
tar xjvf avrnacl-20140813.tar.bz2
cd avrnacl-20140813/

I'm using the avrnacl_8bitc version and am only using "crypto_secretbox" (which is C only) since it is the only one that will fit inside my attiny. The code can be found in the folder avrnacl-20140813/avrnacl_8bitc/.

 

Do you mean the build invocation of the library itself or the build of my program? The build invocation of the library can be found in the Makefile in the avrnacl-20140813/avrnacl_8bitc/ folder.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, uploaded asm dump without initialization "= {0}" in the auth_encrypt wrapper method to see what difference that would make. Update with the code as I posted it: http://pastebin.com/FDvtyErH

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CRYPTO_MAX_LEN is 50, crypto_secretbox_ZEROBYTES is 32. So c and m are 82 bytes long. I'll check now to see whether they aren't longer after calculations are done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The lengths of the arrays c and m are as expected after calculations, both with and without dummy variable. Only difference is that without the dummy variable they contain garbage.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What warnings do you get?

Does the value of the unused global change?

I suggest making it const volatile.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, its value does not change. Making it const volatile didn't change anything.

I'm getting one warning:

 

ISO C90 does not support 'long long' [-Wlong-long]

Long long is used somewhere in the avrnacl library.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rats. I posted a long reply earlier and it seems Freaks barfed so I lost it. Anyway the crux was running nm on the lib to look at the exported data components the using objdump with -s and -j .data to look at what should be in the data section. Very enlightening. How much RAM does a 1634 have anyway? The data should all be LPMd. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I'll try that. The 1634 has 1kB of RAM, the only tiny that does. I tried with an 84a which has 0.5 kB of RAM but got a stack overflow. The part of the library I'm using requires around 700 bytes of RAM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But there are huge initialized data arrays in some of that lib code! No way will it fit 1K.

 

(a mega1284P has 16K)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which part of the library do you mean? I checked with the stack paint routine from some other thread on here (https://www.avrfreaks.net/forum/s...) and it uses 700 bytes of stack memory and I don't think it uses any static RAM.

 

By the way, below is the output of the avr-nm command run on the library file, and the output of the avr-objdump with -s and -j .data in case you would be interested too :)

 

http://pastebin.com/wyqYasMT

 

Contents of section .data:
 800100 06050403 02010165 7870616e 64203332  .......expand 32
 800110 2d627974 65206b05 00000000 00000000  -byte k.........
 800120 00000000 000000fc 65787061 6e642033  ........expand 3
 800130 322d6279 7465206b                    2-byte k        

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using a tablet not the PC where I pulled and built the lib but the ge*.c file has huge arrays (some from a .data file it #includes). 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're right but I'm not using that part of the library (which you obviously had no way of knowing). I only use the crypto_secretbox part which uses the following source files: avrnacl.h, bigint.c, bigint.h, hsalsa20.c, poly1305.c, salsa20_core.c, salsa20.c, verify.c, xsalsa20.c, xsalsa20poly1305.c.
When I include these files in my project instead of the library .a file I get the same results. Of these files only 3 use static RAM:

from poly1305.c:

static const unsigned char minusp[17] = {
  5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 252
} ;

from salsa20.c

static const unsigned char sigma[16] = "expand 32-byte k";

from xsalsa20.c

static const unsigned char sigma[16] = "expand 32-byte k";

And this is exactly what I was seeing in the output of objdump -s -j .data. Thanks by the way for pointing out the use of objdump in this way (and avr-nm as well), they are very useful tools!

Contents of section .data:
 800100 06050403 02010165 7870616e 64203332  .......expand 32
 800110 2d627974 65206b05 00000000 00000000  -byte k.........
 800120 00000000 000000fc 65787061 6e642033  ........expand 3
 800130 322d6279 7465206b                    2-byte k  

  

The "06050403020101" part are 7 dummy initialized global 1 byte-variables (the ones that magically make the library work, although I don't need 7 for this; 1 is enough) that I defined in my code with values 6,5,4,3,2,1 and 1. Then follows the sigma[16] from salsa20.c, the minusp[17] from poly1305.c and sigma[16] from xsalsa20.c. So I have a total of 56 bytes of static RAM usage if I'm not mistaken. Together with a maximum stack size of 700 bytes this is below the 1kB that the tiny1634 has. 

 

Last Edited: Sat. Mar 12, 2016 - 12:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I was wrong when I said that I got no different behaviour when including the source files in my project vs using the built library. When I include the library's source files and build them myself the library always returns the correct results. So I guess the difference must be in the compile flags.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found the problem, it wasn't in the compile flags but in the stripping of the library in the library's Makefile. If I comment out the following line when building the library my code behaves as expected (both with and without dummy variable):

 

$(STRIP) -g --strip-unneeded obj/libnacl.a $^

Still don't know why this causes that weird dummy variable problem though.

 

Here's the output of avr-nm for the stripped library (i.e. the one that's causing the problem): http://pastebin.com/6TaxYLWp

 

and the one without stripping: http://pastebin.com/BUH58w9n

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But stripping is just about the presence/absence of DWARF2. As this has nothing to do with the final binary when you are dealing with AVRs I don't see how that could have an effect? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure either why this changes anything but it surely does (it fixes the problem). It also affects my binary: with the non-stripped library flash size is 8162 bytes, with the stripped one 8140 bytes (output from avrdude). 

Last Edited: Sat. Mar 12, 2016 - 11:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When looking at the output of avr-nm I see that all occurences of "do_copy_data" are removed for the stripped library. Might it have something to do with this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I strip it with

avr-strip -g --strip-unneeded --keep-symbol=__do_copy_data libnacl.a

my code works fine and in this case the binary size is the same as with the non-stripped library. Is this a bug in avr-strip --strip-unneeded?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's something else going on as this has nothing to do with stripping which is only about whether the ELF holds -g info (DWARF2). 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nimyz wrote:
I uploaded the asm dump here

The bit I was interested in was this:

0000007c <__do_copy_data>:
      7c:   11 e0           ldi r17, 0x01   ; 1
      7e:   a0 e0           ldi r26, 0x00   ; 0
      80:   b1 e0           ldi r27, 0x01   ; 1
      82:   ea e6           ldi r30, 0x6A   ; 106
      84:   ff e1           ldi r31, 0x1F   ; 31
      86:   02 c0           rjmp    .+4         ; 0x8c <__do_copy_data+0x10>
      88:   05 90           lpm r0, Z+
      8a:   0d 92           st  X+, r0
      8c:   a2 33           cpi r26, 0x32   ; 50
      8e:   b1 07           cpc r27, r17
      90:   d9 f7           brne    .-10        ; 0x88 <__do_copy_data+0xc>

So that's basically:

memcpy(0x100, 0x1F6A, 0x31);

My initial suspicions were things like the source (0x1F6A) being too close to the end of the flash but in a 16K AVR (0 .. 0x3FFF) that clearly isn't it.

 

So I guess if you now remove "myvariable " I guess that just reduces the end address from 0x0132 to 0x0131 does it?

 

I pulled/built the library code (crikey it's a huge build!) but in the final .a the only data references I find are:

~/windows/avrnacl-20140813/avrnacl_8bitc/obj$ avr-nm libnacl.a | grep ' D '
00000000 D roundconstants
00000000 D avrnacl_sha512_iv
00000000 D avrnacl_ge25519_base

Presumably when you link against the lib these are reported in your .map file and account for the other 0x31 bytes besides "myvariable" ?

 

I do wonder what all this is though...

~/windows/avrnacl-20140813/avrnacl_8bitc/obj$ avr-objdump -s -j .data libnacl.a 
In archive libnacl.a:

salsa20.o:     file format elf32-avr

Contents of section .data:
 0000 65787061 6e642033 322d6279 7465206b  expand 32-byte k

xsalsa20.o:     file format elf32-avr

Contents of section .data:
 0000 65787061 6e642033 322d6279 7465206b  expand 32-byte k

hsalsa20.o:     file format elf32-avr


salsa20.o:     file format elf32-avr


verify.o:     file format elf32-avr


sha512.o:     file format elf32-avr

Contents of section .data:
 0000 22ae28d7 982f8a42 cd65ef23 91443771  ".(../.B.e.#.D7q
 0010 2f3b4dec cffbc0b5 bcdb8981 a5dbb5e9  /;M.............
 0020 38b548f3 5bc25639 19d005b6 f111f159  8.H.[.V9.......Y
 0030 9b4f19af a4823f92 18816dda d55e1cab  .O....?...m..^..
 0040 420203a3 98aa07d8 be6f7045 015b8312  B........opE.[..
 0050 8cb2e44e be853124 e2b4ffd5 c37d0c55  ...N..1$.....}.U
 0060 6f897bf2 745dbe72 b196163b feb1de80  o.{.t].r...;....
 0070 3512c725 a706dc9b 942669cf 74f19bc1  5..%.....&i.t...
 0080 d24af19e c1699be4 e3254f38 8647beef  .J...i...%O8.G..
 0090 b5d58c8b c69dc10f 659cac77 cca10c24  ........e..w...$
 00a0 75022b59 6f2ce92d 83e4a66e aa84744a  u.+Yo,.-...n..tJ
 00b0 d4fb41bd dca9b05c b5531183 da88f976  ..A....\.S.....v
 00c0 abdf66ee 52513e98 1032b42d 6dc631a8  ..f.RQ>..2.-m.1.
 00d0 3f21fb98 c82703b0 e40eefbe c77f59bf  ?!...'........Y.
 00e0 c28fa83d f30be0c6 25a70a93 4791a7d5  ...=....%...G...
 00f0 6f8203e0 5163ca06 706e0e0a 67292914  o...Qc..pn..g)).
 0100 fc2fd246 850ab727 26c9265c 38211b2e  ./.F...'&.&\8!..
 0110 ed2ac45a fc6d2c4d dfb3959d 130d3853  .*.Z.m,M......8S
 0120 de63af8b 54730a65 a8b2773c bb0a6a76  .c..Ts.e..w<..jv
 0130 e6aeed47 2ec9c281 3b358214 852c7292  ...G....;5...,r.
 0140 6403f14c a1e8bfa2 013042bc 4b661aa8  d..L.....0B.Kf..
 0150 9197f8d0 708b4bc2 30be5406 a3516cc7  ....p.K.0.T..Ql.
 0160 1852efd6 19e892d1 10a96555 240699d6  .R........eU$...
 0170 2a207157 85350ef4 b8d1bb32 70a06a10  * qW.5.....2p.j.
 0180 c8d0d2b8 16c1a419 53ab4151 086c371e  ........S.AQ.l7.
 0190 99eb8edf 4c774827 a8489be1 b5bcb034  ....LwH'.H.....4
 01a0 635ac9c5 b30c1c39 cb8a41e3 4aaad84e  cZ.....9..A.J..N
 01b0 73e36377 4fca9c5b a3b8b2d6 f36f2e68  s.cwO..[.....o.h
 01c0 fcb2ef5d ee828f74 602f1743 6f63a578  ...]...t`/.Coc.x
 01d0 72abf0a1 1478c884 ec39641a 0802c78c  r....x...9d.....
 01e0 281e6323 faffbe90 e9bd82de eb6c50a4  (.c#.........lP.
 01f0 1579c6b2 f7a3f9be 2b5372e3 f27871c6  .y......+Sr..xq.
 0200 9c6126ea ce3e27ca 07c2c021 c7b886d1  .a&..>'....!....
 0210 1eebe0cd d67ddaea 78d16eee 7f4f7df5  .....}..x.n..O}.
 0220 ba6f1772 aa67f006 a698c8a2 c57d630a  .o.r.g.......}c.
 0230 ae0df9be 04983f11 1b471c13 350b711b  ......?..G..5.q.
 0240 847d0423 f577db28 9324c740 7babca32  .}.#.w.(.$.@{..2
 0250 bcbec915 0abe9e3c 4c0d109c c4671d43  .......<L....g.C
 0260 b6423ecb bed4c54c 2a7e65fc 9c297f59  .B>....L*~e..).Y
 0270 ecfad63a ab6fcb5f 1758474a 8c19446c  ...:.o._.XGJ..Dl

sha512.o:     file format elf32-avr


hmac.o:     file format elf32-avr


poly1305.o:     file format elf32-avr


consts.o:     file format elf32-avr

Contents of section .data:
 0000 6a09e667 f3bcc908 bb67ae85 84caa73b  j..g.....g.....;
 0010 3c6ef372 fe94f82b a54ff53a 5f1d36f1  <n.r...+.O.:_.6.
 0020 510e527f ade682d1 9b05688c 2b3e6c1f  Q.R.......h.+>l.
 0030 1f83d9ab fb41bd6b 5be0cd19 137e2179  .....A.k[....~!y

fe25519.o:     file format elf32-avr

Contents of section .data:
 0000 edffffff ffffffff ffffffff ffffffff  ................
 0010 ffffffff ffffffff ffffffff ffffff7f  ................

bigint.o:     file format elf32-avr


curve25519.o:     file format elf32-avr

Contents of section .data:
 0000 09000000 00000000 00000000 00000000  ................
 0010 00000000 00000000 00000000 00000000  ................
 0020 42db0100 00000000 00000000 00000000  B...............
 0030 00000000 00000000 00000000 00000000  ................

curve25519.o:     file format elf32-avr


xsalsa20poly1305.o:     file format elf32-avr


curve25519xsalsa20poly1305.o:     file format elf32-avr

Contents of section .data:
 0000 65787061 6e642033 322d6279 7465206b  expand 32-byte k

ed25519.o:     file format elf32-avr


ge25519.o:     file format elf32-avr

Contents of section .data:
 0000 1ad5258f 602d56c9 b2a72595 60c72c69  ..%.`-V...%.`.,i
 0010 5cdcd6fd 31e2a4c0 fe536ecd d3366921  \...1....Sn..6i!
 0020 58666666 66666666 66666666 66666666  Xfffffffffffffff
 0030 66666666 66666666 66666666 66666666  ffffffffffffffff
 0040 01000000 00000000 00000000 00000000  ................
 0050 00000000 00000000 00000000 00000000  ................
 0060 a3ddb7a5 b38ade6d f5525177 809ff020  .......m.RQw... 
 0070 7de3ab64 8e4eea66 65768bd7 0f5f8767  }..d.N.fev..._.g
 0080 00000000 00000000 00000000 00000000  ................
 0090 00000000 00000000 00000000 00000000  ................
 00a0 01000000 00000000 00000000 00000000  ................
 00b0 00000000 00000000 00000000 00000000  ................
 00c0 1ad5258f 602d56c9 b2a72595 60c72c69  ..%.`-V...%.`.,i
 00d0 5cdcd6fd 31e2a4c0 fe536ecd d3366921  \...1....Sn..6i!
 00e0 58666666 66666666 66666666 66666666  Xfffffffffffffff
 00f0 66666666 66666666 66666666 66666666  ffffffffffffffff
 0100 0ece4328 4ea1c583 5fa4d715 458e0d08  ..C(N..._...E...
 0110 ace73318 7d3b043d 6c045a9f 4c38ab36  ..3.};.=l.Z.L8.6
 0120 c9a3f86a ae465f0e 56513864 510f3997  ...j.F_.VQ8dQ.9.
 0130 561fa2c9 e85ea21d c2292309 f3cd6022  V....^...)#...`"
 0140 5ce2f8d3 5f4862ac 86486281 19984363  \..._Hb..Hb...Cc
 0150 3ac8da3e 74aef41f 498f9222 4a9cae67  :..>t...I.."J..g
 0160 d4b4f578 4868c302 04032467 17ec169f  ...xHh....$g....
 0170 f79e2660 8ea126a1 ab69ee77 d1b16712  ..&`..&..i.w..g.
 0180 70f8c9c4 57a63a49 4715ce93 c19e731a  p...W.:IG.....s.
 0190 f920357a b8d42583 46f1cf56 dba83d20  . 5z..%.F..V..= 
 01a0 2f1132ca 61ab38df f00f2fea 3228f24c  /.2.a.8.../.2(.L
 01b0 6c71d580 85b80e47 e19515cb 27e8d047  lq.....G....'..G
 01c0 33f22e32 c09c4091 a5e11b3e f919285c  3..2..@....>..(\
 01d0 dea52dd1 f77ceffc 7b58e3ad 3ea7fd49  ..-..|..{X..>..I
 01e0 edc876d6 831fd210 5d0b4389 ca2e2831  ..v.....].C...(1
 01f0 66469289 146e2ce0 6faefe98 b225485f  fF...n,.o....%H_
 0200 3df2cb7d 1a743a78 27447b6c 8299e5a1  =..}.t:x'D{l....
 0210 be290add c0acae62 1c60457a ba97974c  .).....b.`Ez...L
 0220 f47e49f9 d07ad2c1 606b4d94 067c41f9  .~I..z..`kM..|A.
 0230 777d4ffd a709b71d a1d88628 fce34d05  w}O........(..M.
 0240 07410ef5 1a985558 95cef1bb f309e883  .A....UX........
 0250 07811d4b 19eee3e9 4ebdf4fc 85865614  ...K....N.....V.
 0260 b862409f b5c4c412 3df2abf7 462b88f0  .b@.....=...F+..
 0270 41ad36dd 6864ce87 2fd5472b e363c531  A.6.hd../.G+.c.1
 0280 c884a508 bcfd873b 998b6980 7bc63aeb  .......;..i.{.:.
 0290 93cf4ef8 5c2d8642 b671d797 5fe14267  ..N.\-.B.q.._.Bg
 02a0 b4b937fc a95b2f1e 93e41e62 fc3c7881  ..7..[/....b.<x.
 02b0 8ff38a66 096fad6e 7973e5c9 0006d321  ...f.o.nys.....!
 02c0 59f1b226 949bd6eb 56b18382 9a14e000  Y..&....V.......
 02d0 30d1f3ee f2808e19 e7fcdf56 dcd90624  0..........V...$
 02e0 a3785913 ca4deb75 abd84141 4d0a7000  .xY..M.u..AAM.p.
 02f0 98e87977 7940c78c 73fe6f2b ee6c0352  ..ywy@..s.o+.l.R
 0300 b0a00e4a 271beec4 78e42fad 0618432f  ...J'...x./...C/
 0310 a7d7fb3d 99004d2b 0bdfc14f 8024832b  ...=..M+...O.$.+

sc25519.o:     file format elf32-avr

Contents of section .data:
 0000 edd3f55c 1a631258 d69cf7a2 def9de14  ...\.c.X........
 0010 00000000 00000000 00000000 00000010  ................
 0020 1b132c0a a3e59ced a7296308 5d210621  ..,......)c.]!.!
 0030 ebffffff ffffffff ffffffff ffffffff  ................
 0040 0f                                   .               

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I remove the dummy variable "myvariable" when using the stripped library (the one that's automatically built without changing makefile) I do not get a _do_copy_data section at all. If I remove the stripping part from the Makefile (or build the library myself from source) I do not get any change in the _do_copy_data section (same end address 0x0132) when using the dummy variable or not. Maybe the dummy variable is optimized away since it isn't used?

0000007c <__do_copy_data>:
      7c:	11 e0       	ldi	r17, 0x01	; 1
      7e:	a0 e0       	ldi	r26, 0x00	; 0
      80:	b1 e0       	ldi	r27, 0x01	; 1
      82:	e4 e8       	ldi	r30, 0x84	; 132
      84:	fe e1       	ldi	r31, 0x1E	; 30
      86:	02 c0       	rjmp	.+4      	; 0x8c <__do_copy_data+0x10>
      88:	05 90       	lpm	r0, Z+
      8a:	0d 92       	st	X+, r0
      8c:	a2 33       	cpi	r26, 0x32	; 50
      8e:	b1 07       	cpc	r27, r17
      90:	d9 f7       	brne	.-10     	; 0x88 <__do_copy_data+0xc>
      92:	0e 94 ea 0e 	call	0x1dd4	; 0x1dd4 <main>
      96:	0c 94 40 0f 	jmp	0x1e80	; 0x1e80 <_exit>

Note that the code flash size changed compared to what I posted earlier but that's because I removed some other stuff.

 

The asm dump of my binary when using the non-stripped library differs from the stripped one only in the part where the library is called (when using the dummy variable that is, otherwise I don't get a _copy_data_section), it for instance contains a section <ld32> that is called by the lib. I still wonder why my binary is affected when stripping the library. 

 

This is what the linker is producing (looks the same for both stripped and non-stripped library and with/without dummy variable):

.data           0x00800100       0x32 load address 0x00001e84
                0x00800100                PROVIDE (__data_start, .)
 *(.data)
 .data          0x00800100        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/../../../../avr/lib/avr35/crttn1634.o
 .data          0x00800100        0x1 obj/crypto/crypto_main.o
                0x00800100                myvar
 .data          0x00800101        0x0 obj/crypto/crypto_nacl.o
 .data          0x00800101        0x0 obj/crypto/crypto_spi_slave.o
 .data          0x00800101        0x0 obj/crypto/spi_slave.o
 .data          0x00800101        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(xsalsa20poly1305.o)
 .data          0x00800101        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(xsalsa20.o)
 .data          0x00800101        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(hsalsa20.o)
 .data          0x00800101        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(poly1305.o)
 .data          0x00800101        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(bigint.o)
 .data          0x00800101        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(salsa20.o)
 .data          0x00800101        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(salsa20.o)
 .data          0x00800101        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(verify.o)
 .data          0x00800101        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_mulhi3.o)
 .data          0x00800101        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_exit.o)
 .data          0x00800101        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_copy_data.o)
 .data          0x00800101        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_prologue.o)
 .data          0x00800101        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_epilogue.o)
 .data          0x00800101        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/../../../../avr/lib/avr35/libc.a(memcpy.o)
 *(.data*)
 *(.rodata)
 .rodata        0x00800101       0x10 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(xsalsa20.o)
 .rodata        0x00800111       0x11 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(poly1305.o)
 .rodata        0x00800122       0x10 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(salsa20.o)
 *(.rodata*)
 *(.gnu.linkonce.d*)
                0x00800132                . = ALIGN (0x2)
                0x00800132                _edata = .
                0x00800132                PROVIDE (__data_end, .)

.bss            0x00800132        0x0
                0x00800132                PROVIDE (__bss_start, .)
 *(.bss)
 .bss           0x00800132        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/../../../../avr/lib/avr35/crttn1634.o
 .bss           0x00800132        0x0 obj/crypto/crypto_main.o
 .bss           0x00800132        0x0 obj/crypto/crypto_nacl.o
 .bss           0x00800132        0x0 obj/crypto/crypto_spi_slave.o
 .bss           0x00800132        0x0 obj/crypto/spi_slave.o
 .bss           0x00800132        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(xsalsa20poly1305.o)
 .bss           0x00800132        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(xsalsa20.o)
 .bss           0x00800132        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(hsalsa20.o)
 .bss           0x00800132        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(poly1305.o)
 .bss           0x00800132        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(bigint.o)
 .bss           0x00800132        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(salsa20.o)
 .bss           0x00800132        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(salsa20.o)
 .bss           0x00800132        0x0 lib/avrnacl-20140813_stripped/avrnacl_8bitc/obj/libnacl.a(verify.o)
 .bss           0x00800132        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_mulhi3.o)
 .bss           0x00800132        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_exit.o)
 .bss           0x00800132        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_copy_data.o)
 .bss           0x00800132        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_prologue.o)
 .bss           0x00800132        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/avr35/libgcc.a(_epilogue.o)
 .bss           0x00800132        0x0 /usr/local/CrossPack-AVR-20131216/lib/gcc/avr/4.8.1/../../../../avr/lib/avr35/libc.a(memcpy.o)

 

Last Edited: Mon. Mar 14, 2016 - 11:56 AM