Re: newt size improvements

[Simon Ratner]

Win10 / msys2-x64, gcc versions below. I'll try to poke around as well when
I get a chance.

$ gcc --version
gcc.exe (Rev2, Built by MSYS2 project) 6.2.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 5.4.1
20160919 (release) [ARM/embedded-5-branch revision 240496]
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



On Tue, Feb 28, 2017 at 12:21 AM, Michał Narajowski <
michal.narajow...@codecoup.pl> wrote:

> Hi Simon,
>
> could you give us more info about your setup, so we can reproduce the
> problem? I don't think Mynewt supports Windows.
>
> Michał
>
> 2017-02-27 21:12 GMT+01:00 Szymon Janc :
>
> > Hi Simon,
> >
> > On 27 February 2017 at 19:04, Simon Ratner  wrote:
> > > Clean was the first thing I tried too, didn't help. I am building from
> > the
> > > command line, but on Windows; perhaps it has something to do with path
> > > parsing in the map file?
> >
> > Hmm I think we tested this only on Linux and Mac... will check it
> tomorrow
> > in the office.
> >
> > --
> > pozdrawiam
> > Szymon K. Janc
> >
>

Re: newt size improvements

[Sterling Hughes]

We do!

Sterling 

Sent from my iPhone

> On Feb 28, 2017, at 12:21 AM, Michał Narajowski 
>  wrote:
> 
> Hi Simon,
> 
> could you give us more info about your setup, so we can reproduce the
> problem? I don't think Mynewt supports Windows.
> 
> Michał
> 
> 2017-02-27 21:12 GMT+01:00 Szymon Janc :
> 
>> Hi Simon,
>> 
>>> On 27 February 2017 at 19:04, Simon Ratner  wrote:
>>> Clean was the first thing I tried too, didn't help. I am building from
>> the
>>> command line, but on Windows; perhaps it has something to do with path
>>> parsing in the map file?
>> 
>> Hmm I think we tested this only on Linux and Mac... will check it tomorrow
>> in the office.
>> 
>> --
>> pozdrawiam
>> Szymon K. Janc
>> 

Re: newt size improvements

[Michał Narajowski]

Hi Simon,

could you give us more info about your setup, so we can reproduce the
problem? I don't think Mynewt supports Windows.

Michał

2017-02-27 21:12 GMT+01:00 Szymon Janc :

> Hi Simon,
>
> On 27 February 2017 at 19:04, Simon Ratner  wrote:
> > Clean was the first thing I tried too, didn't help. I am building from
> the
> > command line, but on Windows; perhaps it has something to do with path
> > parsing in the map file?
>
> Hmm I think we tested this only on Linux and Mac... will check it tomorrow
> in the office.
>
> --
> pozdrawiam
> Szymon K. Janc
>

Re: newt size improvements

[Szymon Janc]

Hi Simon,

On 27 February 2017 at 19:04, Simon Ratner  wrote:
> Clean was the first thing I tried too, didn't help. I am building from the
> command line, but on Windows; perhaps it has something to do with path
> parsing in the map file?

Hmm I think we tested this only on Linux and Mac... will check it tomorrow
in the office.

-- 
pozdrawiam
Szymon K. Janc

Re: newt size improvements

[Simon Ratner]

Clean was the first thing I tried too, didn't help. I am building from the
command line, but on Windows; perhaps it has something to do with path
parsing in the map file?

On 27 Feb. 2017 9:03 am, "Szymon Janc"  wrote:

> Hi,
>
> On 27 February 2017 at 17:19, Sterling Hughes
>  wrote:
> > I had the same problem and solution.  Also, make sure you are using the
> > “right” (arm-elf-eabi-none-nm) nm.  The native nm on Mac OS X doesn’t
> > provide the right information.
> >
> > Sterling
> >
> >
> > On 27 Feb 2017, at 2:36, Szymon Janc wrote:
> >
> >> Hi Simon,
> >>
> >> On 26 February 2017 at 23:53, Simon Ratner  wrote:
> >>>
> >>> Looks neat, but when I run it, I don't get the tree -- everything is
> >>> lumped
> >>> under "(other)". Any ideas?
> >>
> >>
> >> I initially had the same issue but this was gone when I did 'newt clean'
> >> and rebuild everything from scratch. Not sure why this was needed.
>
> So did few more tests and it looks like building from Eclipse (as
> described on
> Codecoup blog) seems to result in flat structure for 'newt size -F'.
>
> While building from shell it seems to work just fine. Will need to
> figure it out why:)
>
> --
> pozdrawiam
> Szymon K. Janc
>

Re: newt size improvements

[Szymon Janc]

Hi,

On 27 February 2017 at 17:19, Sterling Hughes
 wrote:
> I had the same problem and solution.  Also, make sure you are using the
> “right” (arm-elf-eabi-none-nm) nm.  The native nm on Mac OS X doesn’t
> provide the right information.
>
> Sterling
>
>
> On 27 Feb 2017, at 2:36, Szymon Janc wrote:
>
>> Hi Simon,
>>
>> On 26 February 2017 at 23:53, Simon Ratner  wrote:
>>>
>>> Looks neat, but when I run it, I don't get the tree -- everything is
>>> lumped
>>> under "(other)". Any ideas?
>>
>>
>> I initially had the same issue but this was gone when I did 'newt clean'
>> and rebuild everything from scratch. Not sure why this was needed.

So did few more tests and it looks like building from Eclipse (as described on
Codecoup blog) seems to result in flat structure for 'newt size -F'.

While building from shell it seems to work just fine. Will need to
figure it out why:)

-- 
pozdrawiam
Szymon K. Janc

Re: newt size improvements

[Michał Narajowski]

Hi Simon,

good idea about the column limit. I will fix that and send a PR.

Michał

2017-02-27 11:36 GMT+01:00 Szymon Janc :

> Hi Simon,
>
> On 26 February 2017 at 23:53, Simon Ratner  wrote:
> > Looks neat, but when I run it, I don't get the tree -- everything is
> lumped
> > under "(other)". Any ideas?
>
> I initially had the same issue but this was gone when I did 'newt clean'
> and rebuild everything from scratch. Not sure why this was needed.
>
> --
> pozdrawiam
> Szymon K. Janc
>

Re: newt size improvements

[Szymon Janc]

Hi Simon,

On 26 February 2017 at 23:53, Simon Ratner  wrote:
> Looks neat, but when I run it, I don't get the tree -- everything is lumped
> under "(other)". Any ideas?

I initially had the same issue but this was gone when I did 'newt clean'
and rebuild everything from scratch. Not sure why this was needed.

-- 
pozdrawiam
Szymon K. Janc

Re: newt size improvements

[Simon Ratner]

Also, any chance output could be limited to 80 columns?

On Sun, Feb 26, 2017 at 2:53 PM, Simon Ratner  wrote:

> Looks neat, but when I run it, I don't get the tree -- everything is
> lumped under "(other)". Any ideas?
>
> On Sun, Feb 26, 2017 at 2:09 PM, Vipul Rahane  wrote:
>
>> +1. Looks quite useful.
>>
>> > On Feb 26, 2017, at 7:51 AM, Jim Jagielski  wrote:
>> >
>> > +1
>> >> On Feb 23, 2017, at 1:16 PM, Sterling Hughes <
>> sterling.hughes.pub...@gmail.com> wrote:
>> >>
>> >> Neat :)  You parse an elf and write sections to a sqlite db, and then
>> allow queries against that.
>> >>
>> >> Sterling
>> >>
>> >>> On 23 Feb 2017, at 10:13, Kevin Townsend wrote:
>> >>>
>> >>> This looks really useful, and saves a lot of manual poking and
>> prodding to figure this out from the command line! Nice PR.
>> >>>
>> >>> We have an oddball Python utility we wrote here that I personally
>> find useful for this kind of thing as well. It opens up an ELF file (ergo
>> the utility name) and you can run SQL queries against the contents of the
>> ELF file.
>> >>>
>> >>> https://github.com/adafruit/Adafruit_Legolas
>> >>>
>> >>> So you can do something like this:
>> >>>
>> >>> |legolas elfquery  "SELECT TO_HEX(Value, 8) AS Value, Size,
>> Section, Name FROM symbols WHERE Section = '.bss' ORDER BY Size DESC LIMIT
>> 5"|
>> >>>
>> >>> And get a result like this:
>> >>>
>> >>> |Value Size Section Name  -- - --
>> 20003570 1580 .bss nvm_data 20002B00 848 .bss APP_TIMER_BUF.9419 20003350
>> 404 .bss m_cmd_queue 20003008 376 .bss m_hids 20002EF0 160 .bss cmd_buffer
>> Query returned 5 rows.|
>> >>>
>> >>> Not sure if that's useful and being in Python it's not going to
>> integrate easily into the current Go apps for Mynewt, but the newt size
>> additions made me think of that and I thought I'd mention it in case
>> someone finds some use for SQL + ELF.
>> >>>
>> >>> Kevin
>> >>>
>>  On 23/02/17 19:04, Sterling Hughes wrote:
>>  Hi,
>> 
>>  Just a quick note (with kudos) that I merged a PR from Michal (in
>> CC) that improves newt size, and it’s really freaking awesome. Thanks
>> Michal!
>> 
>>  Sterling
>> 
>>  Try it out with your targets:
>> 
>>  “””
>>  This patch improves the output of the size command. The output is
>> now similar to `make ram_report` and `make rom_report` in Zephyr. New flags
>> were added for this purpose:
>> 
>>  Flags:
>>  -F, --flash   Print FLASH statistics
>>  -R, --ram Print RAM statistics
>> 
>>  The size statistics are broken down into a tree-like structure, where
>>  the leaves are symbols and branches are folders and files. For
>>  each tree element there its size in bytes and percentage contribution
>>  to the total size of the memory region.
>>  “””
>>  Size of Application Image: app
>>  FLASH report:
>>  Path Size %
>>  
>> ===
>>  (other)  458 0.34%
>>  __isr_vector   248 0.18%
>>  ble_ll_state_set12 0.01%
>>  ble_uuid_length 6 0.00%
>>  hal_debugger_connected16 0.01%
>>  os_sched_next_task12 0.01%
>>  os_time_get12 0.01%
>>  schemes.1048032 0.02%
>>  suffixes.10484   112 0.08%
>>  vfprintf 8 0.01%
>>  apps2012614.83%
>>  bletiny 2012614.83%
>>  src 2012614.83%
>>  cmd.c 13064 9.62%
>>  bletiny_keystore_parse_keydata_help80
>>0.06%
>>  cmd_adv   876 0.65%
>>  cmd_b_exec52 0.04%
>>  cmd_chrup   112 0.08%
>>  cmd_conn   832 0.61%
>>  cmd_datalen   224 0.17%
>>  cmd_disc20 0.01%
>>  cmd_disc_chr   212 0.16%
>>  cmd_disc_dsc   136 0.10%
>>  cmd_disc_full   132 0.10%
>>  cmd_disc_help48 0.04%
>>  cmd_disc_svc   204 0.15%
>>  cmd_exec56 0.04%
>>  cmd_find20 0.01%
>>  cmd_find_entries24 0.02%
>>  cmd_find_help48 0.04%
>>  cmd_find_inc_svcs   

Re: newt size improvements

[Vipul Rahane]

+1. Looks quite useful.

> On Feb 26, 2017, at 7:51 AM, Jim Jagielski  wrote:
> 
> +1
>> On Feb 23, 2017, at 1:16 PM, Sterling Hughes 
>>  wrote:
>> 
>> Neat :)  You parse an elf and write sections to a sqlite db, and then allow 
>> queries against that.
>> 
>> Sterling
>> 
>>> On 23 Feb 2017, at 10:13, Kevin Townsend wrote:
>>> 
>>> This looks really useful, and saves a lot of manual poking and prodding to 
>>> figure this out from the command line! Nice PR.
>>> 
>>> We have an oddball Python utility we wrote here that I personally find 
>>> useful for this kind of thing as well. It opens up an ELF file (ergo the 
>>> utility name) and you can run SQL queries against the contents of the ELF 
>>> file.
>>> 
>>> https://github.com/adafruit/Adafruit_Legolas
>>> 
>>> So you can do something like this:
>>> 
>>> |legolas elfquery  "SELECT TO_HEX(Value, 8) AS Value, Size, Section, 
>>> Name FROM symbols WHERE Section = '.bss' ORDER BY Size DESC LIMIT 5"|
>>> 
>>> And get a result like this:
>>> 
>>> |Value Size Section Name  -- - -- 
>>> 20003570 1580 .bss nvm_data 20002B00 848 .bss APP_TIMER_BUF.9419 20003350 
>>> 404 .bss m_cmd_queue 20003008 376 .bss m_hids 20002EF0 160 .bss cmd_buffer 
>>> Query returned 5 rows.|
>>> 
>>> Not sure if that's useful and being in Python it's not going to integrate 
>>> easily into the current Go apps for Mynewt, but the newt size additions 
>>> made me think of that and I thought I'd mention it in case someone finds 
>>> some use for SQL + ELF.
>>> 
>>> Kevin
>>> 
 On 23/02/17 19:04, Sterling Hughes wrote:
 Hi,
 
 Just a quick note (with kudos) that I merged a PR from Michal (in CC) that 
 improves newt size, and it’s really freaking awesome. Thanks Michal!
 
 Sterling
 
 Try it out with your targets:
 
 “””
 This patch improves the output of the size command. The output is now 
 similar to `make ram_report` and `make rom_report` in Zephyr. New flags 
 were added for this purpose:
 
 Flags:
 -F, --flash   Print FLASH statistics
 -R, --ram Print RAM statistics
 
 The size statistics are broken down into a tree-like structure, where
 the leaves are symbols and branches are folders and files. For
 each tree element there its size in bytes and percentage contribution
 to the total size of the memory region.
 “””
 Size of Application Image: app
 FLASH report:
 Path Size %
 ===
 (other)  458 0.34%
 __isr_vector   248 0.18%
 ble_ll_state_set12 0.01%
 ble_uuid_length 6 0.00%
 hal_debugger_connected16 0.01%
 os_sched_next_task12 0.01%
 os_time_get12 0.01%
 schemes.1048032 0.02%
 suffixes.10484   112 0.08%
 vfprintf 8 0.01%
 apps2012614.83%
 bletiny 2012614.83%
 src 2012614.83%
 cmd.c 13064 9.62%
 bletiny_keystore_parse_keydata_help80 0.06%
 cmd_adv   876 0.65%
 cmd_b_exec52 0.04%
 cmd_chrup   112 0.08%
 cmd_conn   832 0.61%
 cmd_datalen   224 0.17%
 cmd_disc20 0.01%
 cmd_disc_chr   212 0.16%
 cmd_disc_dsc   136 0.10%
 cmd_disc_full   132 0.10%
 cmd_disc_help48 0.04%
 cmd_disc_svc   204 0.15%
 cmd_exec56 0.04%
 cmd_find20 0.01%
 cmd_find_entries24 0.02%
 cmd_find_help48 0.04%
 cmd_find_inc_svcs   136 0.10%
 cmd_help48 0.04%
 cmd_init16 0.01%
 cmd_keystore20 0.01%
 cmd_keystore_add   444 0.33%
 cmd_keystore_del88 0.06%
 cmd_keystore_help48 0.04%
 cmd_keystore_iterator   220 0.16%
 cmd_keystore_parse_keydata   240 0.18%
 cmd_keystore_show

Re: newt size improvements

[Jim Jagielski]

+1
> On Feb 23, 2017, at 1:16 PM, Sterling Hughes 
>  wrote:
> 
> Neat :)  You parse an elf and write sections to a sqlite db, and then allow 
> queries against that.
> 
> Sterling
> 
> On 23 Feb 2017, at 10:13, Kevin Townsend wrote:
> 
>> This looks really useful, and saves a lot of manual poking and prodding to 
>> figure this out from the command line! Nice PR.
>> 
>> We have an oddball Python utility we wrote here that I personally find 
>> useful for this kind of thing as well. It opens up an ELF file (ergo the 
>> utility name) and you can run SQL queries against the contents of the ELF 
>> file.
>> 
>> https://github.com/adafruit/Adafruit_Legolas
>> 
>> So you can do something like this:
>> 
>> |legolas elfquery  "SELECT TO_HEX(Value, 8) AS Value, Size, Section, 
>> Name FROM symbols WHERE Section = '.bss' ORDER BY Size DESC LIMIT 5"|
>> 
>> And get a result like this:
>> 
>> |Value Size Section Name  -- - -- 
>> 20003570 1580 .bss nvm_data 20002B00 848 .bss APP_TIMER_BUF.9419 20003350 
>> 404 .bss m_cmd_queue 20003008 376 .bss m_hids 20002EF0 160 .bss cmd_buffer 
>> Query returned 5 rows.|
>> 
>> Not sure if that's useful and being in Python it's not going to integrate 
>> easily into the current Go apps for Mynewt, but the newt size additions made 
>> me think of that and I thought I'd mention it in case someone finds some use 
>> for SQL + ELF.
>> 
>> Kevin
>> 
>> On 23/02/17 19:04, Sterling Hughes wrote:
>>> Hi,
>>> 
>>> Just a quick note (with kudos) that I merged a PR from Michal (in CC) that 
>>> improves newt size, and it’s really freaking awesome. Thanks Michal!
>>> 
>>> Sterling
>>> 
>>> Try it out with your targets:
>>> 
>>> “””
>>> This patch improves the output of the size command. The output is now 
>>> similar to `make ram_report` and `make rom_report` in Zephyr. New flags 
>>> were added for this purpose:
>>> 
>>> Flags:
>>>  -F, --flash   Print FLASH statistics
>>>  -R, --ram Print RAM statistics
>>> 
>>> The size statistics are broken down into a tree-like structure, where
>>> the leaves are symbols and branches are folders and files. For
>>> each tree element there its size in bytes and percentage contribution
>>> to the total size of the memory region.
>>> “””
>>> Size of Application Image: app
>>> FLASH report:
>>> Path Size %
>>> ===
>>> (other)  458 0.34%
>>> __isr_vector   248 0.18%
>>> ble_ll_state_set12 0.01%
>>> ble_uuid_length 6 0.00%
>>> hal_debugger_connected16 0.01%
>>> os_sched_next_task12 0.01%
>>> os_time_get12 0.01%
>>> schemes.1048032 0.02%
>>> suffixes.10484   112 0.08%
>>> vfprintf 8 0.01%
>>> apps2012614.83%
>>> bletiny 2012614.83%
>>> src 2012614.83%
>>> cmd.c 13064 9.62%
>>> bletiny_keystore_parse_keydata_help80 0.06%
>>> cmd_adv   876 0.65%
>>> cmd_b_exec52 0.04%
>>> cmd_chrup   112 0.08%
>>> cmd_conn   832 0.61%
>>> cmd_datalen   224 0.17%
>>> cmd_disc20 0.01%
>>> cmd_disc_chr   212 0.16%
>>> cmd_disc_dsc   136 0.10%
>>> cmd_disc_full   132 0.10%
>>> cmd_disc_help48 0.04%
>>> cmd_disc_svc   204 0.15%
>>> cmd_exec56 0.04%
>>> cmd_find20 0.01%
>>> cmd_find_entries24 0.02%
>>> cmd_find_help48 0.04%
>>> cmd_find_inc_svcs   136 0.10%
>>> cmd_help48 0.04%
>>> cmd_init16 0.01%
>>> cmd_keystore20 0.01%
>>> cmd_keystore_add   444 0.33%
>>> cmd_keystore_del88 0.06%
>>> cmd_keystore_help48 0.04%
>>> cmd_keystore_iterator   220 0.16%
>>> cmd_keystore_parse_keydata   240 0.18%
>>> cmd_keystore_show   128 0.09%
>>> cmd_l2cap20 0.01%
>>> cmd_l2cap_connect   156 0.11%
>>> cmd_l2cap_create_srv   140