Re: Size optimization for objects

["Rego, P." <pvrego@gmail.com>]

On Thursday, July 11, 2013 6:10:05 AM UTC-3, Niklas Holsti wrote:
> (For the record, I understand from your preceding message that this is
> the output of "nm --print-size --size-sort bla.exe".)
Yes.

> > 00414176 ffbec001 D ___gl_locking_policy
> > 00414175 ffbec001 D ___gl_queuing_policy
> > 00414174 ffbec001 D ___gl_task_dispatching_policy
> 
> This is starting to look like a bug in your "nm". The three variables
> above are clearly of size 1 octet (the addresses differ by 1 octet at
> each step) but the "size" column is not 00000001.
I agree.

> An example where the size (of the first object) is evidently 2 octets
> (I'm quoting these line pairs in address order, not in the original size
> order):
> > 00414b36 ffbec002 D _ada__exceptions__exception_traces__nlineXn
> > 00414b38 ffbec004 D ___gnat_exception_actions_global_action
> And 3 octets:
> > 00414b41 ffbec003 D _system__stack_checking__multi_processor
> > 00414b44 ffbec00c D _system__stack_checking__null_stack_info
> And 4 octets:
> > 00414b38 ffbec004 D ___gnat_exception_actions_global_action
> > 00414b3c ffbec004 D ___gnat_exception_actions_initialized
> In each case, in the "size" column, the last three hex digits show the
> correct size, but the first five are "ffbec", clearly wrong for a size
> value.
Yes, it makes sense.

> Sorting the whole listing into address order shows that the first five
> hex digits of the "size" column behave in a systematic manner: the list
> starts with 857 lines with "ffbff" in these digits, and all these
> symbols are of type "t" or "T". The next line is type "D" and has
> "ffbec" in these digits. I haven't tried to discover any rules for this,
> since there is evidently a bug in your "nm", producing these incorrect
> "size" values.
I will try it with another version to see the results.