[Bug ld/32100] --rosegment moves the build-id note away from the start of the file

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug gas/31979] DW_LNE_set_discriminator emitted right before Special Opcodes

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #2 from Mark Wielaard  ---
One idea might be gnulib's git-version-gen:
https://git.savannah.gnu.org/cgit/gnulib.git/plain/modules/git-version-gen
https://git.savannah.gnu.org/cgit/gnulib.git/tree/build-aux/git-version-gen

Do note that binutils-gdb is a shared repo so there probably should be
consensus by both projects to change this.

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

[Bug ld/30002] pr26391-5, pr26391-6 ld test failures on sparc64-unknown-linux-gnu since 496afd17055aeb7d8f45e01715c475664f2b73bd

[mark at klomp dot org]

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

--- Comment #14 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #13)
> Created attachment 14602 [details]
> Try this one

Note that since the gentoo-sparc builder also does binutils-try builds you can
try by pushing to a branch starting with try- under your users name. e.g
push origin :users/hjl/try-pr30002

More documentation here: https://sourceware.org/binutils/wiki/Buildbot

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

[Bug ld/30002] pr26391-5, pr26391-6 ld test failures on sparc64-unknown-linux-gnu since 496afd17055aeb7d8f45e01715c475664f2b73bd

[mark at klomp dot org]

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

--- Comment #10 from Mark Wielaard  ---
(In reply to cvs-com...@gcc.gnu.org from comment #9)
> The try-PR26391 branch has been updated by Mark Wielaard
> :
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=99175c84026b1bfa534f3946150535c39027911d
> 
> commit 99175c84026b1bfa534f3946150535c39027911d
> Author: Sam James 
> Date:   Mon Jan 16 14:03:02 2023 -0800

Sorry, that was me, but a) I mistyped the correct branch name and b) changed
the Author to Sam to show which emails the buildbot sents out.

The actual try build with this patch is actually here:
https://builder.sourceware.org/buildbot/#/changes/17250

try builders for binutils are described here:
https://sourceware.org/binutils/wiki/Buildbot

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

[Bug ld/30002] pr26391-5, pr26391-6 ld test failures on sparc64-unknown-linux-gnu since 496afd17055aeb7d8f45e01715c475664f2b73bd

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #3 from Mark Wielaard  ---
See also https://sourceware.org/bugzilla/show_bug.cgi?id=26391#c10

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

[Bug binutils/29993] objcopy --merge-notes slow for large .so with many annobin notes

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size

[mark at klomp dot org]

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

--- Comment #11 from Mark Wielaard  ---
(In reply to Jan Beulich from comment #8)
> (In reply to Mark Wielaard from comment #7)
> > > and the symbol size is also 0 in the table:
> > > $ readelf -s crti.o
> > >
> > > Symbol table '.symtab' contains 11 entries:
> > >Num:Value  Size TypeBind   Vis  Ndx Name
> > > ...
> > >  9:  0 FUNCGLOBAL HIDDEN 5 _init
> > 
> > So if the size really is zero than high_pc should be one larger than low_pc
> > (if expressed as addr in DWARF < 4) and 1 if expressed as unsigned constant
> > (for DWARF >=4)
> > 
> > Having the addresses equal or high_pc zero does not express the zero sized
> > region.
> 
> Doesn't high_pc being one larger than low_pc express a 1-byte region?

Yes, you are right. Technically since high_pc is one past the last address it
describes just a single address (of low_pc).

To describe a DIE without size you should only emit a low_pc attribute and no
high_pc attribute.

According to the DWARF spec a DIE  that has a machine code
address or range of machine code addresses associated has:

• A DW_AT_low_pc attribute for a single address,
• A DW_AT_low_pc and DW_AT_high_pc pair of attributes for a single
contiguous range of addresses, or
• A DW_AT_ranges attribute for a non-contiguous range of addresses.

Where the high_pc expresses the first location past the last instruction
associated with the entity.

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

[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size

[mark at klomp dot org]

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

--- Comment #7 from Mark Wielaard  ---
> and the symbol size is also 0 in the table:
> $ readelf -s crti.o
>
> Symbol table '.symtab' contains 11 entries:
>Num:Value  Size TypeBind   Vis  Ndx Name
> ...
>  9:  0 FUNCGLOBAL HIDDEN 5 _init

So if the size really is zero than high_pc should be one larger than low_pc (if
expressed as addr in DWARF < 4) and 1 if expressed as unsigned constant (for
DWARF >=4)

Having the addresses equal or high_pc zero does not express the zero sized
region.

It is a little questionable that the low_pc address is also zero, is that
because it doesn't have relocations applied yet?

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

[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size

[mark at klomp dot org]

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

--- Comment #5 from Mark Wielaard  ---
>> So when this file is linked in with object files and these relocations are
>> resolved the correct values for the __x86.get_pc_thunk.bx symbol will be
>> installed into the .debug_info section, and everything should work.
>
> In https://sourceware.org/PR29450 we observed zero-size on a final executable.

Maybe it is useful to attach the final binary to this bug and show how to
generate it.

Given the code that introduced this issues (commit
591cc9fbbfd6d51131c0f1d4a92e7893edcc7a28 see comment #1) it might also be
interesting to show the symbol table entry for _init.

Also maybe try building with -gdwarf-4 or -gdwarf-5 to see what/how high_pc is
encoded then (as offset from low_pc).

> These are DW_AT_low_pc=_init, DW_AT_high_pc=_init. AFAIU DW_AT_high_pc
> should be somehting like _init+2 to at least account for `ud2`.

Right, the DW_AT_high_pc should at least be one bigger than low_pc or it
doesn't encode a valid single range.

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

[Bug binutils/29075] objdump -S does not support debuginfod

[mark at klomp dot org]

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

--- Comment #13 from Mark Wielaard  ---
(In reply to Martin Liska from comment #12)
> > So in order for -S to work, we either have to add debuginfod support to the
> > BFD library or else add a new find_nearest_line() type function to
> > binutils/dwarf.c.  I wonder which would be the best approach ?
> 
> @fche, @mark: Can you please express what would be better out of the 2
> options?

Sorry I am not an expert in the abstractions used by bfd. But it looks to me
that if _bfd_dwarf2_find_nearest_line needs the debuginfo then it should be
called (through _bfd_elf_find_line?) making sure the debuginfo is available.

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

[Bug gas/29451] gas-2.39 started adding 0-sized DIEs to functions without .size

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #2 from Mark Wielaard  ---
(In reply to Sergei Trofimovich from comment #0)
> Discovered in https://sourceware.org/PR29450 where gas-2.38 did not attach
> 0-sized DIE for glibc's _init assembly-written function and gas-2.39 did.
> 
>  <1><22>: Abbrev Number: 2 (DW_TAG_subprogram)
> <23>   DW_AT_name: (strp) (offset: 0x49): _init
> <27>   DW_AT_external: (flag) 1
> <28>   DW_AT_low_pc  : (addr) 0x0
> <2c>   DW_AT_high_pc : (addr) 0x0
> 
> Would it be fair to say it's a bug to assign zero size here via DW_AT_low_pc
> / DW_AT_high_pc?

Yes it is clearly a bug. Both low_pc and high_pc are invalid values.

The definition of low_pc/high_pc is:

  The value of the DW_AT_low_pc attribute is the address of the first
instruction associated with the entity.

  If the value of the DW_AT_high_pc is of class address, it is the address of
the first location past the last instruction associated with the entity;

So this doesn't even describe a valid contiguous range.

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

[Bug binutils/29075] objdump -S does not support debuginfod

[mark at klomp dot org]

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

--- Comment #7 from Mark Wielaard  ---
So more specifically whenever objdump -S cannot find the sources it can try to
call debuginfod_find_source () just like it tries to find the original
debuginfo through debuginfod_find_debuginfo. See the documentation in
debuginfod.h:

/* Query the urls contained in $DEBUGINFOD_URLS for a file with
   the specified type and build id.  If build_id_len == 0, the
   build_id is supplied as a lowercase hexadecimal string; otherwise
   it is a binary blob of given length.

   If successful, return a file descriptor to the target, otherwise
   return a posix error code.  If successful, set *path to a
   strdup'd copy of the name of the same file in the cache.
   Caller must free() it later. */

int debuginfod_find_debuginfo (debuginfod_client *client,
   const unsigned char *build_id,
   int build_id_len,
   char **path);

int debuginfod_find_executable (debuginfod_client *client,
const unsigned char *build_id,
int build_id_len,
char **path);

int debuginfod_find_source (debuginfod_client *client,
const unsigned char *build_id,
int build_id_len,
const char *filename,
char **path);

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

[Bug binutils/29075] objdump -S does not support debuginfod

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC|mjw at fedoraproject dot org   |mark at klomp dot org

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

[Bug ld/28915] dwarf2.c doesn't correctly parse DW_UT_skeleton

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug gold/23535] gold needs to produce two PT_NOTE segments with ELFCLASS64

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug gold/28494] New: gold combines different aligned/padded SHT_NOTE sections in the same PT_NOTE segment

[mark at klomp dot org]

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

Bug ID: 28494
   Summary: gold combines different aligned/padded SHT_NOTE
sections in the same PT_NOTE segment
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gold
  Assignee: ccoutant at gmail dot com
  Reporter: mark at klomp dot org
CC: ian at airs dot com, mliska at suse dot cz
  Target Milestone: ---

Minimal reproducer:

$ echo 'main() { return 0; }' | gcc -x c - -fuse-ld=gold && ./elflint --gnu-ld
a.out
:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
phdr[6]: unknown object file note type 32 with owner name '' at offset 48
phdr[6]: extra 72 bytes after last note

$ ld.gold --version
GNU gold (GNU Binutils; openSUSE Tumbleweed 2.37.20210803-1) 1.16

$ eu-readelf -l a.out
Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  PHDR   0x40 0x00400040 0x00400040 0x000230
0x000230 R   0x8
  INTERP 0x000270 0x00400270 0x00400270 0x1c
0x1c R   0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD   0x00 0x0040 0x0040 0x000688
0x000688 R E 0x1000
  LOAD   0x000e08 0x00401e08 0x00401e08 0x000208
0x000209 RW  0x1000
  DYNAMIC0x000e18 0x00401e18 0x00401e18 0x0001b0
0x0001b0 RW  0x8
  NOTE   0x0002b0 0x004002b0 0x004002b0 0x30
0x30 R   0x8
  NOTE   0x00028c 0x0040028c 0x0040028c 0x78
0x78 R   0x4
  GNU_EH_FRAME   0x000664 0x00400664 0x00400664 0x24
0x24 R   0x4
  GNU_STACK  0x00 0x 0x 0x00
0x00 RW  0x10
  GNU_RELRO  0x000e08 0x00401e08 0x00401e08 0x0001f8
0x0001f8 RW  0x8

 Section to Segment mapping:
  Segment Sections...
   00 
   01  [RO: .interp]
   02  [RO: .interp .note.ABI-tag .note.gnu.property .note.gnu.build-id
.dynsym .dynstr .gnu.hash .hash .gnu.version .gnu.version_r .rela.dyn .init
.text .fini .rodata .eh_frame .eh_frame_hdr]
   03  [RELRO: .fini_array .init_array .dynamic .got .got.plt] .data .bss
   04  [RELRO: .dynamic]
   05  [RO: .note.gnu.property]
   06  [RO: .note.ABI-tag .note.gnu.property .note.gnu.build-id]
   07  [RO: .eh_frame_hdr]
   08 
   09  [RELRO: .fini_array .init_array .dynamic .got .got.plt]

Note:

  05  [RO: .note.gnu.property]
  06  [RO: .note.ABI-tag .note.gnu.property .note.gnu.build-id]

Both segment 05 and segment 06 cover .note.gnu.property, and segment 06 mixes
notes using alignment 8 (causing different padding) and alignment 4
(.note.gnu.property is sandwiched between .note.ABI-tag and
.note.gnu.build-id).

This makes it impossible to properly parse the second PT_NOTE segment.

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

[Bug ld/2378] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug ld/6019] [avr] avr-ld --relax requires --gc-sections

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug gas/1038] resolution of weak symbol not left for the linker if value is already known

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug binutils/27797] [size] attempting double-free on bfd/mach-o.c:5978

[mark at klomp dot org]

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

--- Comment #7 from Mark Wielaard  ---
realloc with size zero is super confusing, so much so that C11 deprecated the
use of calling realloc with size zero:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_400

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

[Bug gas/27215] as: Error: non-constant .uleb128 is not supported on riscv64

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC|mjw at fedoraproject dot org   |mark at klomp dot org

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

[Bug ld/27226] ld.bfd contains huge .rodata section

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC|mjw at fedoraproject dot org   |

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

[Bug ld/26706] pad strings in .dynstr

[mark at klomp dot org]

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

--- Comment #4 from Mark Wielaard  ---
Hi Ben,

Bugzilla tricked you and changed the from so your reply went directly
into the bug.

On Tue, Mar 09, 2021 at 12:41:46AM +, woodard at redhat dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=26706
> 
> --- Comment #3 from Ben Woodard  ---
> Do you think it is worth me chiming in saying ‘what he said’? You captured my
> intent perfectly.  I guess I’m kind of hung up on “assume” in “what I assume
> Ben, the original reporter, is after” or is that just a polite assume.

So you just did chime in with an "what he said". Thanks!
Of course it was a polite assume, I always try to be polite :)

Just didn't want to put any words in your mouth, even though I was
pretty sure because we had discussed the way Solaris solved it
before. Just wanted to provide some background pointers. But yes, it
probably should have read "what I know", but that sounded so
presumptious.

Cheers,

Mark

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

[Bug ld/26706] pad strings in .dynstr

[mark at klomp dot org]

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

--- Comment #2 from Mark Wielaard  ---
(In reply to Fangrui Song from comment #1)
> You can additionally link an object file with an artificial long symbol
> name. Since that symbol is not used, you can change its .dynstr

I think that is really fragile. The way Solaris does this (what I assume Ben,
the original reporter, is after) is by introducing a new dynamic section entry
that provides the padding that is still available. That way tools know where
and how much space they can use for dynamic strings.

We could introduce DT_GNU_STRPAD and suggest that linkers initially set it to
256 (and add that to DT_STRSZ) to make such manipulations easy and robust. Any
tool manipulating the .dynstr segement can then use (and update) that when
adding a new string.

See also: http://www.linker-aliens.org/blogs/ali/entry/changing_elf_runpaths/

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

[Bug binutils/27484] clang++: objdump: DWARF error: could not find variable specification at offset

[mark at klomp dot org]

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

--- Comment #6 from Mark Wielaard  ---
Comment on attachment 13273
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13273
object file - ICC

That does look like the same issue. It also generates an DW_AT_specification
with a forward reference. GCC would emit the DW_TAG_variable after the
declaration, so you will only see references to DIEs that you have already seen
in the tree.

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

[Bug binutils/27478] [readelf] warning about missing section in separate debug info file

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug binutils/27484] clang++: objdump: DWARF error: could not find variable specification at offset

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC|mjw at fedoraproject dot org   |

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

[Bug binutils/27484] clang++: objdump: DWARF error: could not find variable specification at offset

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #1 from Mark Wielaard  ---
Note the DW_TAG_variable DIE DW_AT_specification attribute refers to a
DW_TAG_member DIE that comes later in the CU. g++ would place those in the
opposite order, so you don't only have to look backwards in the CU.

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

[Bug gold/27246] ld.gold does not support DWARF5

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug binutils/27231] objdump -S doesn't work on DWARF5 generated by GCC 11

[mark at klomp dot org]

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

--- Comment #10 from Mark Wielaard  ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to H.J. Lu from comment #6)
> > 
> >   if ((low_pc == 0 && high_pc == 0) || low_pc == high_pc)
> > return FALSE;
> > 
> > in read_rnglists().  Is this a GCC 11 bug?
> 
> No, binutils bug.
> There is nothing special about 0 low or high pc or low_pc == high_pc in
> .debug_rnglists.  The list termination is rather DW_RLE_end_of_list.

The DWARF5 spec does indeed explicitly say:
"A bounded range entry whose beginning and ending address offsets are equal
(including zero) indicates an empty range and may be ignored."
So your patch
https://sourceware.org/pipermail/binutils/2021-January/115073.html looks
correct.

Note that arange_add already ignores empty ranges, so just remove the whole
check should be equivalent to the check plus explicit continue.

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

[Bug ld/27226] ld.bfd contains huge .rodata section

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #2 from Mark Wielaard  ---

> $ eu-elfcompress -n '.*rodata' -t zlib ld.bfd -o ld.xxx -v
> processing: ld.bfd
> [17] .rodata ignoring allocated section

It is as the message says. .rodata is an allocated section (SHF_ALLOC) and so
cannot be ELF section compressed. This is explicitly not allowed by the spec
because it would make mapping such a section into memory awkward (there is no
corresponding program header flag, so it would be unclear how the dynamic
linker should map a segment that contains a compressed section, especially
since the segment/section mapping isn't 1-on-1 and can be about partial
sections).

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

[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist

[mark at klomp dot org]

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

--- Comment #11 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #10)
> A patch is posted at
> 
> https://sourceware.org/pipermail/binutils/2020-October/113938.html

Thanks. I get what is going on now. This isn't a normal .dwo file, it is one
processed with dwp. In that case you do indeed need to take the offsets from
the .debug_cu_index into account. eu-readelf also doesn't do that. I filed a
bug for that: https://sourceware.org/bugzilla/show_bug.cgi?id=26812

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

[Bug binutils/26808] [2.36 Regression] readelf: Warning: DIE at offset 0x232 refers to abbreviation number 77 which does not exist

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #3 from Mark Wielaard  ---
(In reply to Nick Clifton from comment #1)
> Hmm, I think that maybe the test file is corrupt.  The elfutils version of
> readelf appears to support this:
> 
>   % eu-readelf -w dwp_test_1.dwp > /dev/null
>   [..various warnings and errors and then...]
>   eu-readelf: cannot get tag of DIE at offset [232] in section
> '.debug_info.dwo': invalid DWARF
> 
> Is it possible that the test, or gold itself, is broken ?

It seems broken indeed, but it is hard to tell what is going on without the
main file that contains the skeleton DIEs [the various warnings and errors are
about trying to parse the .dwo without the main .debug DIEs]. How was this file
generated?

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

[Bug gas/26778] Error: file table slot 1 is already occupied by a different file

[mark at klomp dot org]

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

--- Comment #1 from Mark Wielaard  ---
Introduced by:

commit bd0c565edbf4ba8121fded38e389530d7fa6f963
Author: H.J. Lu 
Date:   Sat Oct 17 04:24:22 2020 -0700

gas: Always use as_where for preprocessed assembly codes

Always clear the slot 1 if it was assigned to the input file before the
first .file  directive has been seen.  Always use as_where to
generate the correct debug infor for preprocessed assembly codes.

PR gas/25878
PR gas/26740
* dwarf2dbg.c (allocate_filename_to_slot): Don't reuse the slot 1
here.
(dwarf2_where): Restore as_where.
(dwarf2_directive_filename): Clear the slot 1 if it was assigned
to the input file.
* testsuite/gas/i386/dwarf5-line-2.d: New file.
* testsuite/gas/i386/dwarf5-line-2.s: Likewise.
* testsuite/gas/i386/dwarf5-line-3.d: Likewise.
* testsuite/gas/i386/dwarf5-line-3.s: Likewise.
* testsuite/gas/i386/i386.exp: Run dwarf5-line-2 and
dwarf5-line-3.

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

[Bug gas/26778] Error: file table slot 1 is already occupied by a different file

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug gas/25878] Error: file table slot 1 is already occupied by a different file

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug gas/26740] Extra filename generated by --gdwarf-4

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||nickc at sourceware dot org

--- Comment #4 from Mark Wielaard  ---
Note that the auto_assigned moving of file entries was done because of PR25878.
Maybe Nick knows why the entries needed to be moved instead of simply being
reassigned.

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

[Bug gas/26740] Extra filename generated by --gdwarf-4

[mark at klomp dot org]

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

--- Comment #3 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #2)
> (In reply to Mark Wielaard from comment #1)
> > The issue is that some instructions are emitted (dwarf2_emit_insn is called)
> > before the first .file  directive has been seen. This allocates x.s
> > (the input file) as first file entry. Later when the actual .file 1
> > lbasename.c and .file 2 safe-ctype are seen the x.s entry is moved to entry
> > 3. We don't record that we never actually use that entry and so we still
> > emit it.
> 
> Is this a GCC bug? Even if it is, assembler shouldn't generate bad debug
> info.

I don't think so. Although it might help if gcc emitted the .file 1 directive
earlier. The debug info isn't really bad, but it does contain an unused file
name which it really shouldn't. I am not yet sure how to fix that. 

In gas/dwarf2dbg.c you see that the file entry is moved when a .file NUM is
seen and the file entry is auto_assigned. I wonder if we should just replace it
instead of moving if dwarf2_any_loc_directive_seen is false (because then we
know it has never been used).

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

[Bug gas/26740] Extra filename generated by --gdwarf-4

[mark at klomp dot org]

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

--- Comment #1 from Mark Wielaard  ---
The issue is that some instructions are emitted (dwarf2_emit_insn is called)
before the first .file  directive has been seen. This allocates x.s
(the input file) as first file entry. Later when the actual .file 1 lbasename.c
and .file 2 safe-ctype are seen the x.s entry is moved to entry 3. We don't
record that we never actually use that entry and so we still emit it.

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

[Bug ld/26706] pad strings in .dynstr

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC

[mark at klomp dot org]

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

--- Comment #3 from Mark Wielaard  ---
(In reply to Szabolcs Nagy from comment #2)
> i don't know about sh_entsize, i will have to check what it should be.

In general sh_size modulo sh_entsize needs to be zero (if sh_entsize isn't zero
itself). For non-zero sh_entsize sections, elfutils libelf will flag a section
as  corrupt if the sh_size % sh_entsize != 0.

In this case, given that you have entries of variable size, I believe
sh_entsize should be zero.

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

[Bug ld/26312] ld produces broken PLT on aarch64 with BTI+PAC

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

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

[Bug ld/24717] .note.gnu.property sections are not stored at an offset equal to their VMA in debuginfo files

[mark at klomp dot org]

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

--- Comment #6 from Mark Wielaard  ---
(In reply to Nick Clifton from comment #5)
> Presumably it would make sense to silence this warning when processing .debug
> files.  Is there a reliable way to detect them ?  For example can such files
> always be assumed to have a .text section with a SHT_NOBITS type ?

There was a proposal to give such files a unique (ET_GNU_DEBUG_REL|EXEC|DYN)
type. But that was never implemented. So you would indeed need some heuristic.
Such files don't have any allocated SHT_PROGBITS sections. The only allocated
sections are SHT_NOBITS or SHT_NOTES.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/24717] .note.gnu.property sections are not stored at an offset equal to their VMA in debuginfo files

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #2 from Mark Wielaard  ---
A main executable and a separate debug file have the exact same program
headers. This is to make matching them together easier. It also helps to have
to original program headers in the debug file for unstrip when the main
executable file has been prelinked, so you can still recombine them.

You cannot rely on the program headers in a .debug file since all allocated
sections (except for SHT_NOTES) have been replaced by NOBITS.

The reason this seems to work out for the .build_id NOTE is because it is
always put at the front of the file, so no other sections are removed before it
when put into a .debug file (and so the offset stays the same).

If you want this to work for any other allocated NOTEs then the linker would
have to sort them together at the front of the file (right after the .build-id
NOTE, the .build-id NOTE should always be first, so it gets dumped with the ELF
headers in a core file).

But in general I would say that programs that rely on the program headers in a
split .debug file are just broken.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23919
Bug 23919 depends on bug 23916, which changed state.

Bug 23916 Summary: [bisected] elifutils-0.175 broke kernel's objtool 
(elifutils-0.173 works)
https://sourceware.org/bugzilla/show_bug.cgi?id=23916

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment

[mark at klomp dot org]

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

--- Comment #11 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #9)
> This change triggered
> 
> gcctestdir/collect-ld: warning: gdb_index_test_cdebug_gabi.o: section
> .debug_str contains incorrectly aligned strings; the alignment of those
> strings won't be preserved
> gcctestdir/collect-ld: warning: gdb_index_test_3.o: section .debug_str
> contains incorrectly aligned strings; the alignment of those strings won't
> be preserved
> gcctestdir/collect-ld: error: treating warnings as errors
> collect2: error: ld returned 1 exit status 
> make[3]: *** [gdb_index_test_3] Error 1 
> 
> in gold tests.

I think this comes from do_add_input_section in gold/merge.cc.
It decompresses the section, but doesn't use ch_addralign, but
this->addralign(), when calculating the alignment constraint.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment

[mark at klomp dot org]

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

--- Comment #10 from Mark Wielaard  ---
(In reply to cvs-com...@gcc.gnu.org from comment #6)
> The master branch has been updated by H.J. Lu :
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> h=131a5a648d314cd15811158150573cb40eb3abd0
> 
> commit 131a5a648d314cd15811158150573cb40eb3abd0
> Author: H.J. Lu 
> Date:   Tue Nov 27 06:02:36 2018 -0800
> 
> Initialize *uncompressed_align_pow_p to 0
> 
> Initialize *uncompressed_align_pow_p to 0 since *uncompressed_align_pow_p
> is passed to bfd_is_section_compressed_with_header as uninitialized,
> 
>   PR binutils/23919
>   * compress.c (bfd_is_section_compressed_with_header): Initialize
>   *uncompressed_align_pow_p to 0.

I think this is correct, the uncompressed_align_pow_p wasn't set explicitly
when the compressed section was gnu-zlib, in which case the alignment has to be
assumed to be always 1.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment

[mark at klomp dot org]

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

--- Comment #4 from Mark Wielaard  ---
(In reply to Nick Clifton from comment #3)
>   Thanks very much for the bug report, and especially for a patch to fix it!
>   I have applied the patch, so I hope that this problem is now resolved.

Thanks!

>   One very minor point - in the future, would you mind providing the
>   ChangeLog entries as plain text, rather than a context diff ?  It
>   did not matter this time, but often the diff will not apply because
>   the changelog has changed by the time that the patch is applied.

OK, I will in the future.
Do you have some script that helps you handle separate ChangeLog entries?

Note that gnulib contains some helpers for merging ChangeLog entries that I
have used somewhat successfully with mercurial and git. They work the other way
around though, you explicitly do add the ChangeLog entries in the
commit/ChangeLog file, but when a merge action takes place they handle the
entry specially.

https://gnu.wildebeest.org/blog/mjw/2012/03/16/automagically-merging-changelog-files-with-mercurial-or-git/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/23919] bfd doesn't handle ELF compressed data alignment

[mark at klomp dot org]

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

--- Comment #1 from Mark Wielaard  ---
Created attachment 11413
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11413&action=edit
Proposed patch to handle compressed section alignment correctly

The attached git format-patch resolved this issue by handling the
(de)compressed section alignment correctly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/23919] New: bfd doesn't handle ELF compressed data alignment

[mark at klomp dot org]

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

Bug ID: 23919
   Summary: bfd doesn't handle ELF compressed data alignment
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: mark at klomp dot org
CC: devurandom at gmx dot net, elfutils-devel at sourceware dot 
org,
    mark at klomp dot org, slyfox at inbox dot ru,
unassigned at sourceware dot org
Depends on: 23916
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #23916 +++

The ELF compression header has a field (ch_addralign) that is set to the
alignment of the uncompressed section. This way the section itself can have a
different alignment than the decompressed section. bfd (and readelf) however
explicitly make the section sh_addralign and ch_addralign equal. It also always
sets the alignment to 1 which is wrong when using a Elf32_Chdr (which has
alignment of 4) or Elf64_Chdr (which has alignment of 8).

This shows up with tools that use elfutils libelf which sets up the alignment
correctly.

First gas creates a compressed section with on alignment of 1.
Second libelf accepts this, but corrects the alignment when it
writes out the section.
Third bfd_check_compression_header sanity checks the section alignment,
but it checks that the compressed and decompressed alignment is equal?!?
I think it wanted to check that the alignment is a power of 2 instead.


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=23916
[Bug 23916] [bisected] elifutils-0.175 broke kernel's objtool (elifutils-0.173
works)
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22911] Huge slowdown in objdump -d caused by scanning the dynamic relocs

[mark at klomp dot org]

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

--- Comment #7 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #6)
> A patch is posted at
> 
> https://sourceware.org/ml/binutils/2018-03/msg00015.html

Thanks. With that patch my original testcase takes just 11 seconds (from 2
minutes 40 seconds) and the output is identical.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22911] Huge slowdown in objdump -d caused by scanning the dynamic relocs

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #1)
> Which version binutils are you using?

This is with gdb-binutils git master build on RHEL 7.4 with gcc from
devtoolset-7, but also happens when updating the binutils version on Fedora
from f25 (which doesn't have that commit yet) to f27.

> I can't reproduce it on master branch:

It might depend on the testfile used. The libxul.so that I used for testing is
the one packaged with RHEL 7.4. But others have replicated with the libxul.so
as build upstream. The problem seems to be the newly introduced linear search
of the dynamic relocs. So it might depend on whether your testfile has lots of
those.

Julian on CC also has some profiling benchmarks that shows the slowdown comes
from the changes in find_symbol_for_address.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22911] New: Huge slowdown in objdump -d caused by scanning the dynamic relocs

[mark at klomp dot org]

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

Bug ID: 22911
   Summary: Huge slowdown in objdump -d caused by scanning the
dynamic relocs
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: mark at klomp dot org
CC: jseward at acm dot org
  Target Milestone: ---

The following commit:

commit a24bb4f0cce83eea8b2ad1542316651143af6f90
Author: Nick Clifton 
Date:   Tue Oct 11 13:50:10 2016 +0100

Enhance objdump so that it will use .got, .plt and .plt.got section symbols
when disassembling, and it will use dynamic relocs to interpret entries in the
PLT and GOT.

binutils * objdump.c (is_significant_symbol_name): New function.
(remove_useless_symbols): Do not remove significanr symbols.
(find_symbol_for_address): If an exact match for the specified
address has not been found, try scanning the dynamic relocs to see
if one of these matches the address.  If so, use the symbol
associated with the reloc.
(objdump_print_addr_with_symbol): Do not print offsets to symbols
with no value.
(disassemble_section): Only use dynamic relocs if the user
requested this.
(disassemble_data): Always load dynamic relocs if they are
available.

Caused a huge slowdown of disassembling some binaries.

Specifically reverting:
https://sourceware.org/git/?p=binutils-gdb.git;a=blobdiff_plain;f=binutils/objdump.c;h=59abc1189be5643a44405cc71cabb1397ae9f5d8;hp=2d2bddb03ce5fc9093befb61522e05371d783d66;hb=a24bb4f0cce83eea8b2ad1542316651143af6f90;hpb=199fa1b7089d7f7438b087fa30504ea5a590f561

Makes time ./binutils/objdump -d /usr/lib64/firefox/libxul.so > /dev/null go
from:

real2m48.616s
user2m48.242s
sys 0m0.160s

to:

real0m11.781s
user0m11.717s
sys 0m0.064s

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/22749] New: Bad alignment and padding of .note.gnu.property

[mark at klomp dot org]

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

Bug ID: 22749
   Summary: Bad alignment and padding of .note.gnu.property
   Product: binutils
   Version: 2.31 (HEAD)
Status: NEW
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: mark at klomp dot org
  Target Milestone: ---

The .note.gnu.property SHT_NOTE uses wrong alignment and padding on ELFCLASS64.
This breaks note parsers which will see garbage data inside a NOTE and might
flag the ELF file as invalid or stop parsing any note data (since they cannot
know how to skip the note).

Unlike what gabi says, GNU always uses 4 byte alignment and padding, plus 32bit
sizes for namesz and descrsz in notes independent from ELF class.

gabi says to use 8 byte alignment and padding, plus 64bit sizes for ELFCLASS64,
but others (except HPUX it seems) also don't follow that. Nobody uses 8 byte
alignment/padding and 32bit sizes.

This was discussed on the gnu-gabi and gabi mailinglists:
https://sourceware.org/ml/gnu-gabi/2017-q4/msg00028.html

Proposed fix:

diff --git a/bfd/elf-properties.c b/bfd/elf-properties.c
index 2549dd0..647931b 100644
--- a/bfd/elf-properties.c
+++ b/bfd/elf-properties.c
@@ -394,7 +394,8 @@ _bfd_elf_link_setup_gnu_properties (struct bfd_link_info
*info)
   unsigned int descsz;
   bfd_byte *contents;
   Elf_External_Note *e_note;
-  unsigned int align_size = bed->s->elfclass == ELFCLASS64 ? 8 : 4;
+  /* Note GNU SHT_NOTEs are always 4 byte aligned.  */
+  unsigned int align_size = 4;

   sec = bfd_get_section_by_name (first_pbfd,
 NOTE_GNU_PROPERTY_SECTION_NAME);
diff --git a/bfd/elfxx-x86.c b/bfd/elfxx-x86.c
index a7db5d9..e6d45f3 100644
--- a/bfd/elfxx-x86.c
+++ b/bfd/elfxx-x86.c
@@ -2424,7 +2424,12 @@ _bfd_x86_elf_link_setup_gnu_properties
  if (sec == NULL)
info->callbacks->einfo (_("%F%P: failed to create GNU property
section\n"));

- if (!bfd_set_section_alignment (ebfd, sec, class_align))
+   /* GNU ABI always aligns and pads SHT_NOTES 4 bytes.  Using
+  32bit sizes for name_sz and desc_sz.  Independent from
+  the ELF class.  This is different from gabi, which uses
+  alignement and padding of 8 bytes, plus 64bit sizes for
+  ELFCLASS64.  Changing this breaks existing NOTE parsers.  */
+ if (!bfd_set_section_alignment (ebfd, sec, 2))
{
 error_alignment:
  info->callbacks->einfo (_("%F%A: failed to align section\n"),

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22249] objdump --dwarf-start can be very slow

[mark at klomp dot org]

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

--- Comment #13 from Mark Wielaard  ---
(In reply to Tom Tromey from comment #4)
> (In reply to Nick Clifton from comment #2)
> >   * For completeness sake if nothing else, shouldn't we also be able to
> > specify an end address for CU dumping ?
> 
> There are really two cases here.
> 
> One is dumping the CU headers but no DIEs.  That's --dwarf-depth=0.
> In this case you want to dump everything.

IMHO it is totally confusing that printing CU headers or not is specified with
--dwarf-depth=0. Why isn't this a separate option?

> The other is expanding some DIE.  In this case, --dwarf-depth=N
> --dwarf-start=DIE is used;
> the printing stops when the next DIE to be printed would have
> a depth below N.  You can see this in action with the Emacs mode -- if it
> did not stop, you'd get the whole CU inserted when expanding a "...".

This seems somewhat user unfriendly.
How is one supposed to pick the "correct" N?
In the case that --dwarf-start=DIE is given, but --dwarf-depth=N is not,
it really should default to --dwarf-depth=DIE-depth. Otherwise you just
keep dumping completely unrelated DIEs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug ld/13569] Linker garbage collection retains debug information which leads to GDB bus errors

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/15152] readelf and objdump don't print strings from .dwz file

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22249] objdump --dwarf-start can be very slow

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #3 from Mark Wielaard  ---
(In reply to Nick Clifton from comment #2)
>   * According to the documentation the --dwarf-start=N command line option
> (which sets the dwarf_start_die variable) specifies the *number* of the DIE
> at which output should start, not the starting address referenced by the
> DIE.  
> 
>   I think that this may be a mistake in the documentation however, as this
> does not appear to match the behaviour of the code.  Either that, or the
> documentation is correct and the code is wrong.  From the way that the
> documentation is written however, it would appear that the code may be at
> fault.

I made the same observations when a request was made to add similar options to
eu-readelf. There are a couple of other odd corner case behaviours too:
https://sourceware.org/bugzilla/show_bug.cgi?id=22250#c1
I think the documentation could certainly be improved/corrected.
Making it stop at the end of the CU also seems like a good improvement.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22136] Support marking "debug" info files with special ET_GNU_DEBUG_* values.

[mark at klomp dot org]

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

--- Comment #18 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #16)
> (In reply to Mark Wielaard from comment #15)
> > (In reply to H.J. Lu from comment #14)
> > > Anything else besides "identical to the phdrs"?  Must .dynamic section 
> > > have
> > > the identical section contents in debug info file?
> > 
> > Allocated sections are NOBITS in a separate debug file.
> 
> I checked libfoo.so against the output of "objcopy --only-keep-debug".
> Their program headers are different:

That might be a bug. See e.g. eu-strip -f which keeps them intact.
And eu-unstrip depends on this for example.

Anyway, the point is that you are not supposed to use the phdrs offsets of the
separate debug file. So you need some marker in the ELF header to indicate what
kind of ELF file it is.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22136] Support marking "debug" info files with special ET_GNU_DEBUG_* values.

[mark at klomp dot org]

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

--- Comment #15 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #14)
> Anything else besides "identical to the phdrs"?  Must .dynamic section have
> the identical section contents in debug info file?

Allocated sections are NOBITS in a separate debug file.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22136] Support marking "debug" info files with special ET_GNU_DEBUG_* values.

[mark at klomp dot org]

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

--- Comment #13 from Mark Wielaard  ---
(In reply to H.J. Lu from comment #11)
> So the problem is the invalid .dynamic section.  Can we just drop
> .dynamic section with "objcopy --only-keep-debug"

No. The phdrs in a separate debug file are identical to the phdrs from the main
ELF file. That is why you need a marker in the ELF header to know whether or
not to "trust" the phdrs. In a separate debug file you will need to find
information through the shdrs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/22136] Support marking "debug" info files with special ET_GNU_DEBUG_* values.

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21809] gas outputs data symbol markers "$d" in .debug_frame

[mark at klomp dot org]

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

--- Comment #2 from Mark Wielaard  ---
(In reply to Nick Clifton from comment #1)
> Created attachment 10280 [details]
>   Something like this ?
> 
>   Please give it a try and let me know if it works for you.

It seems to work on an armv7l setup. Haven't tested aarch64.
.debug_frame won't get any markers. eh_frame does get one.
But at least that one is at the start of the section
(which is allowed, though unnecessary).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug gas/21809] New: gas outputs data symbol markers "$d" in .debug_frame

[mark at klomp dot org]

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

Bug ID: 21809
   Summary: gas outputs data symbol markers "$d" in .debug_frame
   Product: binutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: mark at klomp dot org
  Target Milestone: ---

On arm and aarch64:

$ echo "int main() { return 1; }" | gcc -g -xc -
$ eu-readelf -S ./a.out | grep debug_frame
[31] .debug_frame PROGBITS  0007c0 30  00   0 
4
$ eu-readelf -s ./a.out | grep '$d' | grep 31
   67: 0010  0 NOTYPE  LOCAL  DEFAULT   31 $d

Note that theoretically it is allowed to have a data marker symbol at the start
of the section if the whole section contains data. But it is redundant and
optional. Also this symbol doesn't point to the start of the section but some
way in.

This is caused by the use of frag_align () in gas/dw2gencfi.c.
It is similar to an issue fixed with .debug_aranges:

commit d025d5e5b57fb59c56aa4d57b7fc138720a8e454
Author: Mark Wielaard 
Date:   Sat Jun 13 17:47:41 2015 -0400

gas: Don't use frag_align but use plain padding to align .debug_aranges.

out_debug_aranges uses frag_align to make sure the addresses start
out aligned. Using frag_align will call frag_var[_init], which will
end up calling TC_FRAG_INIT. On arm and aarch64 TC_FRAG_INIT will
generate a $d mapping symbol for the .debug_aranges to show that at
that point a sequence of data items starts.

Such a symbol pointing into a non-allocated debug section will confuse
eu-strip -g. And it seems inefficient and wrong in general to have
additional mapping symbols for debug sections, which won't contain
actual code in the first place.

Just keep track of the aranges header size and use plain padding to
align the addresses which avoids generating any mapping symbols on
aarch64 and arm.

Includes a testcase for aarch64 that PASS with this patch and shows
the extra $d mapping symbol in .debug_aranges before.

gas/ChangeLog

   * dwarf2dbg.c (out_header): Document EXPR->X_add_number value,
   out_debug_aranges depends on it.
   (out_debug_aranges): Track size of header to properly pad header
   for address alignment.

gas/testsuite/ChangeLog

   * gas/aarch64/dwarf.d: New.
   * gas/aarch64/dwarf.s: New.

It is however not as to remove all uses of frag_align () and replace them with
simple padding in dw2gencfi.c.

It would best if aarch64_init_frag and arm_init_frag could be changed to not
emit marker symbols if the frag is associated with a data only section (like
SEC_DEBUGGING).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

[Bug binutils/20876] objdump is not aware about the build ID method to find detached debug info

[mark at klomp dot org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at klomp dot org

--- Comment #3 from Mark Wielaard  ---
Just a note that elfutils searches only the (global?) absolute debuginfo paths
directly.

So given the default of "":.debug:/usr/lib/debug", it skips the "" relative cwd
and the ".debug" postfix, but only tries /usr/lib/debug/.build-id/xx/.debug

So the search strategy of elfutils for a separate .debug file given a build-id
xx and a list of debuginfo search paths is to take the absolute paths
(starting with '/') and trying /path/.build-id/xx/.debug. Where the default
list of (absolute) debuginfo search paths is just "/usr/lib/debug". It then
takes the canonicalize_file_name assuming it might be a symlink and the user
might find the resolved name more interesting. As a sanity check elfutils also
only allows build-ids that are at a minimum 4 and at a maximum 64 hex
characters long. It does normally also verify that the found file does contain
the build-id it should and reject the file if it doesn't.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils