Re: How create small binaries with GNU binutils.

2019-02-15 Thread Dmitry Bogatov


[2019-02-13 13:17] Nick Clifton 
> [1].  You could check this theory by running "readelf --section-headers 
> --program-headers"
> on the two binaries.  Both should have program headers but, if the 
> theory is right, only the ld generated binary will have section headers.

Checked. Confirmed.

> [...]
> I am sorry, but I think that I going to be unable to help you. :-(

Understood. Thank you for your help. I need to read more about ELF format.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

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


Re: How create small binaries with GNU binutils.

2019-02-13 Thread Nick Clifton
Hi Dmitry,

> Thank you for suggestion, but map did not reveal anything. The only part
> (section?) with non zero size is .text of size 0xd (=13). This is
> correct, raw instructions are really 13 bytes (according to `objdump -d').

> By the way, `readelf --sections' reports, that there is no sections in
> fasm-generated binary. I do not know, how does fasm do it, but probably
> is saves on section headers or something like this. Is is possible to
> make `ld' do the same?

Ah ha - maybe that is it.  Maybe fasm is generating a binary with just
program segments but no sections, whereas ld is generating a binary with
both sections and segments[1].  Unfortunately I do not know of a way to 
tell ld to stop generating the sections.  Unfortunately it also appears
that the objcopy tool does not have an option for removing the sections
either.  (Actually it does, but removing the sections would remove the
code as well, whereas what we want to do is to remove the section header
table but leave in the program header table).

I am sorry, but I think that I going to be unable to help you. :-(

Cheers
  Nick

[1].  You could check this theory by running "readelf --section-headers 
--program-headers"
on the two binaries.  Both should have program headers but, if the 
theory is right, only the ld generated binary will have section headers.

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


Re: How create small binaries with GNU binutils.

2019-02-13 Thread Dmitry Bogatov


[2019-02-07 15:43] Nick Clifton 
>
> part   text/plain 498
> Hi Dmitry,
>
> >>> Still, even this way, 400 bytes is more then twice as big, compared to
> >>> fasm. Any suggestions, how to shrink binary futher?
>
> > Thank you for suggestion. Tried both options; no difference -- 400
> > bytes.
>
> Ho Hum.  In which case, do you know what is in the extra bytes ?  If you
> link with the -Map=foo.map option you should get a map file which shows 
> you how the output was constructed.  Perhaps this can help you find out
> where the extra bytes are coming from.

Thank you for suggestion, but map did not reveal anything. The only part
(section?) with non zero size is .text of size 0xd (=13). This is
correct, raw instructions are really 13 bytes (according to `objdump -d').

According to `readelf --sections', there is only `.text' and `.shstrtab'
sections.

By the way, `readelf --sections' reports, that there is no sections in
fasm-generated binary. I do not know, how does fasm do it, but probably
is saves on section headers or something like this. Is is possible to
make `ld' do the same?

Also, there is PAX_HEADERS header in binutils-generated binary.

Here is map, maybe you could extract more of it:

  Memory Configuration

  Name Origin Length Attributes
  *default*0x 0x

  Linker script and memory map

  LOAD a01.o
  [!provide]PROVIDE (__executable_start 
= SEGMENT_START ("text-segment", 0x40))
  0x004000b0. = (SEGMENT_START 
("text-segment", 0x40) + SIZEOF_HEADERS)

  .interp
   *(.interp)

  .note.gnu.build-id
   *(.note.gnu.build-id)

  .hash
   *(.hash)

  .gnu.hash
   *(.gnu.hash)

  .dynsym
   *(.dynsym)

  .dynstr
   *(.dynstr)

  .gnu.version
   *(.gnu.version)

  .gnu.version_d
   *(.gnu.version_d)

  .gnu.version_r
   *(.gnu.version_r)

  .rela.dyn   0x004000b00x0
   *(.rela.init)
   *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
   *(.rela.fini)
   *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
   *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
   *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
   *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
   *(.rela.ctors)
   *(.rela.dtors)
   *(.rela.got)
   .rela.got  0x004000b00x0 a01.o
   *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
   *(.rela.ldata .rela.ldata.* .rela.gnu.linkonce.l.*)
   *(.rela.lbss .rela.lbss.* .rela.gnu.linkonce.lb.*)
   *(.rela.lrodata .rela.lrodata.* .rela.gnu.linkonce.lr.*)
   *(.rela.ifunc)

  .rela.plt   0x004000b00x0
   *(.rela.plt)
  [!provide]PROVIDE (__rela_iplt_start 
= .)
   *(.rela.iplt)
   .rela.iplt 0x004000b00x0 a01.o
  [!provide]PROVIDE (__rela_iplt_end = 
.)

  .init
   *(SORT_NONE(.init))

  .plt0x004000b00x0
   *(.plt)
   *(.iplt)
   .iplt  0x004000b00x0 a01.o

  .plt.got
   *(.plt.got)

  .plt.sec
   *(.plt.sec)

  .text   0x004000b00xd
   *(.text.unlikely .text.*_unlikely .text.unlikely.*)
   *(.text.exit .text.exit.*)
   *(.text.startup .text.startup.*)
   *(.text.hot .text.hot.*)
   *(.text .stub .text.* .gnu.linkonce.t.*)
   .text  0x004000b00xd a01.o
  0x004000b0_start
   *(.gnu.warning)

  .fini
   *(SORT_NONE(.fini))
  [!provide]PROVIDE (__etext = .)
  [!provide]PROVIDE (_etext = .)
  [!provide]PROVIDE (etext = .)

  .rodata
   *(.rodata .rodata.* .gnu.linkonce.r.*)

  .rodata1
   *(.rodata1)

  .eh_frame_hdr
   *(.eh_frame_hdr)
   *(.eh_frame_entry .eh_frame_entry.*)

  .eh_frame
   *(.eh_frame)
   *(.eh_frame.*)

  .gcc_except_table
   *(.gcc_except_table .gcc_except_table.*)

  .gnu_extab
   *(.gnu_extab*)

  .exception_ranges
   *(.exception_ranges .exception_ranges*)
  0x006000bd. = DATA_SEGMENT_ALIGN 
(CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE))

  .eh_frame
   *(.eh_frame)
   *(.eh_frame.*)

  .gnu_extab
   *(.gnu_extab)

  .gcc_except_table
   *(.gcc_except_table .gcc_except_table.*)

  .exception_ranges
   *(.exception_ranges .exception_ranges*)

  .tdata
   *(.tdata .tdata.* .gnu.linkonce.td.*)

  .tbss
   *(.tbss .tbss.* .gnu.linkonce.tb.*)
   *(.tcommon)

  .preinit_array  0x006000bd0x0
  [!provide]PROVIDE 
(__preinit_array_start = .)
   *(.preinit_array)
  [!provide]PROVIDE 
(__preinit_array_end = .)

  .init_array 0x006000bd0x0
  [!provide]PROVIDE (__init_array_start 
= .)
   *(SO

Re: How create small binaries with GNU binutils.

2019-02-07 Thread Nick Clifton
Hi Dmitry,

>>> Still, even this way, 400 bytes is more then twice as big, compared to
>>> fasm. Any suggestions, how to shrink binary futher?

> Thank you for suggestion. Tried both options; no difference -- 400
> bytes.

Ho Hum.  In which case, do you know what is in the extra bytes ?  If you
link with the -Map=foo.map option you should get a map file which shows 
you how the output was constructed.  Perhaps this can help you find out
where the extra bytes are coming from.

Cheers
  Nick



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


Re: How create small binaries with GNU binutils.

2019-02-05 Thread Dmitry Bogatov


[2019-02-04 09:50] Nick Clifton 
> > Still, even this way, 400 bytes is more then twice as big, compared to
> > fasm. Any suggestions, how to shrink binary futher?
>
> This might be because the linker defaults to page aligning the binaries.
> Have you tried linking with the --nmagic option ?  (Or alternatively the
> --omagic option).

Thank you for suggestion. Tried both options; no difference -- 400
bytes.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

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


Re: How create small binaries with GNU binutils.

2019-02-04 Thread Nick Clifton
Hi Dmitry,

> Still, even this way, 400 bytes is more then twice as big, compared to
> fasm. Any suggestions, how to shrink binary futher?

This might be because the linker defaults to page aligning the binaries.
Have you tried linking with the --nmagic option ?  (Or alternatively the
--omagic option).

Cheers
  Nick


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


Re: How create small binaries with GNU binutils.

2019-02-03 Thread Dmitry Bogatov


[2019-02-01 17:49] Andreas Schwab 
> On Feb 01 2019, Dmitry Bogatov  wrote:
>
> > results in huge binary:
> >
> > $ du -hb a.out
> > 4744a.out
> > $ strip -s a.out
> > $ du -hb a.out
> > 4408a.out
> > $ file a.out
> > a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically 
> > linked, stripped
>
> I cannot reproduce that.
>
> $ stat -c %s a.out
> 664
> $ strip a.out
> $ stat -c %s a.out
> 344
> $ size a.out 
>textdata bss dec hex filename
>  13   0   0  13   d a.out
> $ rpm -q binutils
> binutils-2.31.90-lp150.5.68.1.x86_64

Interesting. I tried bintuils, packaged by Nix, and resulted (after
strip -s) exactly 400 bytes. I will report debian packaging.

Still, even this way, 400 bytes is more then twice as big, compared to
fasm. Any suggestions, how to shrink binary futher?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

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


Re: How create small binaries with GNU binutils.

2019-02-01 Thread Andreas Schwab
On Feb 01 2019, Dmitry Bogatov  wrote:

> results in huge binary:
>
>   $ du -hb a.out
>   4744a.out
>   $ strip -s a.out
>   $ du -hb a.out
>   4408a.out
>   $ file a.out
>   a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically 
> linked, stripped

I cannot reproduce that.

$ stat -c %s a.out
664
$ strip a.out
$ stat -c %s a.out
344
$ size a.out 
   textdata bss dec hex filename
 13   0   0  13   d a.out
$ rpm -q binutils
binutils-2.31.90-lp150.5.68.1.x86_64

Try examining the files with `readelf -a'.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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


How create small binaries with GNU binutils.

2019-02-01 Thread Dmitry Bogatov

[ Not a but, strictly speaking, but just do not know, where else to ask. ]

Hello!

I like AT&T syntax of amd64 assembler, so I am using GNU As.
Unfortunately, it creates binries much bigger then one would expect from
source code.  For compraison, trivial program, that just exits with
value 1 (essentially, /bin/false), implemented in fasm:

;; a02.fasm
format ELF64 executable at 0001h

segment readable executable

entry $
xor edi,edi
inc edi
mov eax,60
syscall

complied in following way

$ fasm a02.fasm
flat assembler  version 1.73.06  (16384 kilobytes memory)
1 passes, 131 bytes.

results in tiny binary.

Equivalent program, compiled and linked with binutils

# a01.S
.globl _start
_start:
xor %di, %di
inc %di
mov $60, %eax
syscall

with following commands:

as a01.S -o a01.o
ld a01.o

results in huge binary:

$ du -hb a.out
4744a.out
$ strip -s a.out
$ du -hb a.out
4408a.out
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically 
linked, stripped

Both `as` and `ld` are from Debian package `binutils=2.31.1-11`.  What
am I doing wrong? Can I force binutils to create small, ~150 bytes
binary?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpvu4cQu7dL_.pgp
Description: PGP signature
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils