[Bug libctf/32305] New: ./configure --help: replace --enable-libctf with --disable-libctf

[dilyan.palauzov at aegee dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32305

Bug ID: 32305
   Summary: ./configure --help: replace --enable-libctf with
--disable-libctf
   Product: binutils
   Version: 2.44 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libctf
  Assignee: unassigned at sourceware dot org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

./configure --help prints:

  --enable-libctf Handle .ctf type-info sections [default=yes]

The output of ./configure --help should, when possible, only mention how to
toggle the defaults, thus implying what the default is.  Consider changing the
above output to

  --disable-libctfDo not handle .ctf type-info sections

I mean this file
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/configure.ac#l130

Lengty reasoning: https://ab.bapha.be/posts/help-output/.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gprofng/32303] New: ./configure --help: replace --enable-gprofng with --disable-gprofng

[dilyan.palauzov at aegee dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32303

Bug ID: 32303
   Summary: ./configure --help: replace --enable-gprofng with
--disable-gprofng
   Product: binutils
   Version: pre-2.15
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gprofng
  Assignee: vladimir.mezentsev at oracle dot com
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

./configure --help prints:

  --enable-gprofng[=ARG]  build gprofng [ARG={yes,no}]

As not providing this option does build gprofng, the above output should be

  --disable-gprofng  do not build gprofng

That is, the output of ./configure --help should just mention how to toggle the
defaults, thus implying what the default is.

I mean this configure.ac file:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=configure.ac#l410

Lengthy reasoning: https://ab.bapha.be/posts/help-output/.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/32308] New: OBJCOPY will gap-fill outside of loaded data

[eleventen at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32308

Bug ID: 32308
   Summary: OBJCOPY will gap-fill outside of loaded data
   Product: binutils
   Version: 2.42
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: eleventen at gmail dot com
  Target Milestone: ---

Created attachment 15763
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15763&action=edit
Linked ELF that OBJDUMPs incorrectly

Greetings,

The attached linked binary was created using the ARM GCC build 12.2.Rel1.  We
have verified the behavior below with both the 12.2.Rel1 version of objcopy and
the 13.3.Rel1 version.

  GNU objcopy (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 2.42.0.20240614

OBJCOPY will emit the binary correctly, unless the --gap-fill option is used or
if the empty .data section is also removed.  We discovered this example because
we had linked our program in a way that included no initialized .data and found
that the objcopy to binary was emitting a 384MiB file.

1) objcopy -O binary fmt0-small fmt0-small.bin

The result is 10912 bytes.

2) objcopy -O binary --gap-fill=0xff fmt0-small fmt0-small.bin

The result 402661376 bytes.

3) objcopy -O binary -R .data --gap-fill=0xff fmt0-small fmt0-small.bin

The result is 10912 bytes.

The section header for .data would normally load with PROGBITS, but in this
case, the section is empty.  We haven't found a way to conditionally emit .data
if it is non-empty which would work-around this particular case with a linker
script.  We could certainly do so with a script.  Yet, it does seem like this
is a glitch in the objdump (or perhaps the linker or BFD library).

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf
Al
  [ 0]   NULL 00 00 00  0   0 
0
  [ 1] .text PROGBITS0800 01 002510 00  AX  0   0 
4
  [ 2] .ARM.extabPROGBITS08002510 012aa0 00 00   W  0   0 
1
  [ 3] .rodata   PROGBITS08002510 012510 00058c 00   A  0   0 
4
  [ 4] .threads  PROGBITS08002a9c 012a9c 04 00   A  0   0 
4
  [ 5] .stacks   NOBITS  2000 02 002000 00  WA  0   0 
1
  [ 6] .data PROGBITS20002000 012aa0 00 00  WA  0   0 
8
  [ 7] .bss  NOBITS  20002000 022000 00040c 00  WA  0   0 
4
  [ 8] .heap NOBITS  2000240c 02240c 02dbf4 00  WA  0   0 
4
  [ 9] .sram2a   NOBITS  2003 02 008000 00  WA  0   0 
4
  [10] .sram2b   NOBITS  20038000 018000 008000 00  WA  0   0 
4
  [11] .bkp  NOBITS  40002850 022850 50 00  WA  0   0 
4
  [12] .crc  PROGBITS08002aa0 012aa0 00 00   A  0   0 
4

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x01 0x0800 0x0800 0x02aa0 0x02aa0 R E 0x1
  LOAD   0x002000 0x20002000 0x08002aa0 0x0 0x0040c RW  0x1
  LOAD   0x00240c 0x2000240c 0x08002aa0 0x0 0x2dbf4 RW  0x1
  LOAD   0x00 0x2000 0x2000 0x0 0x02000 RW  0x1
  LOAD   0x00 0x2003 0x2003 0x0 0x08000 RW  0x1
  LOAD   0x008000 0x20038000 0x20038000 0x0 0x08000 RW  0x1
  LOAD   0x002850 0x40002850 0x40002850 0x0 0x00050 RW  0x1

 Section to Segment mapping:
  Segment Sections...
   00 .text .rodata .threads 
   01 .bss 
   02 .heap 
   03 .stacks 
   04 .sram2a 
   05 .sram2b 

Cheers

-- 
You are receiving this mail because:
You are on the CC list for the bug.