Bug 27309 - readelf --debug-dump=info --wide output changes in 2.36
Summary: readelf --debug-dump=info --wide output changes in 2.36
Status: RESOLVED WONTFIX
Alias: None
Product: binutils
Classification: Unclassified
Component: binutils (show other bugs)
Version: 2.36
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-01 13:04 UTC by Martin Liska
Modified: 2021-02-18 14:13 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Liska 2021-02-01 13:04:19 UTC
After https://sourceware.org/bugzilla/show_bug.cgi?id=26847 the following is printed:

$ ./binutils/readelf --debug-dump=info --wide /tmp/sample_struct.o | head -n20
Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x39c (32-bit)
   Version:       2
   Abbrev Offset: 0x0
   Pointer Size:  4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (strp) (offset: 0x14c): GNU C17 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9] -m32 -mtune=generic -march=x86-64 -gdwarf-2 -fPIE
    <10>   DW_AT_language    : (data1) 12	(ANSI C99)
    <11>   DW_AT_name        : (strp) (offset: 0x12d): mpers-m32/sample_struct.c
    <15>   DW_AT_comp_dir    : (strp) (offset: 0x89): /home/abuild/rpmbuild/BUILD/strace-5.10
    <19>   DW_AT_stmt_list   : (data4) 0x0
 <1><1d>: Abbrev Number: 2 (DW_TAG_base_type)
    <1e>   DW_AT_byte_size   : (data1) 1
    <1f>   DW_AT_encoding    : (data1) 8	(unsigned char)
    <20>   DW_AT_name        : (strp) (offset: 0x56): unsigned char
 <1><24>: Abbrev Number: 2 (DW_TAG_base_type)
    <25>   DW_AT_byte_size   : (data1) 2
    <26>   DW_AT_encoding    : (data1) 7	(unsigned)

before the revision it printed:

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x39c (32-bit)
   Version:       2
   Abbrev Offset: 0x0
   Pointer Size:  4
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x14c): GNU C17 10.2.1 20201202 [revision e563687cf9d3d1278f45aaebd03e0f66531076c9] -m32 -mtune=generic -march=x86-64 -gdwarf-2 -fPIE
    <10>   DW_AT_language    : 12	(ANSI C99)
    <11>   DW_AT_name        : (indirect string, offset: 0x12d): mpers-m32/sample_struct.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x89): /home/abuild/rpmbuild/BUILD/strace-5.10
    <19>   DW_AT_stmt_list   : 0x0
 <1><1d>: Abbrev Number: 2 (DW_TAG_base_type)
    <1e>   DW_AT_byte_size   : 1
    <1f>   DW_AT_encoding    : 8	(unsigned char)
    <20>   DW_AT_name        : (indirect string, offset: 0x56): unsigned char
 <1><24>: Abbrev Number: 2 (DW_TAG_base_type)
    <25>   DW_AT_byte_size   : 2
    <26>   DW_AT_encoding    : 7	(unsigned)

I don't see a point why e.g. "(indirect string, offset: 0x89)" should be replaced with "(strp) (offset: 0x89)" in --wide mode.

Moreover, I broke a strace configure script.
Comment 1 Martin Liska 2021-02-01 13:05:00 UTC
> Moreover, I broke a strace configure script.

* it broke
Comment 2 Nick Clifton 2021-02-01 14:31:32 UTC
Hi Martin,

  The change was made so that the output from the binutils readelf would be closer to that of the elfutils readelf.  Vis:

Old Binutils:
    <14>   DW_AT_name       : (indirect string, offset: 0x69): ../sysdeps/x86_64/crti.S

2.36 Binutils:
   <14>   DW_AT_name        : (strp) (offset: 0x69): ../sysdeps/x86_64/crti.S
 
Elfutils:
          name                (strp) "../sysdeps/x86_64/crti.S"

  The change also means that the form name can be deduced from the output.
  Ie "(strp)" indicates that it was DW_FORM_strp.  Likewise "(addr)" is 
  DW_FORM_addr and so on.

  Readelf has never made any promises regarding the consistency of its 
  output, although I do appreciate that changes like this are annoying
  when they break scripts that are used to the old format.

  Can the strace configure script be adapted to cope with both versions 
  of readelf's output ?

Cheers
  Nick
Comment 3 Martin Liska 2021-02-02 08:41:42 UTC
(In reply to Nick Clifton from comment #2)
> Hi Martin,
> 
>   The change was made so that the output from the binutils readelf would be
> closer to that of the elfutils readelf.  Vis:
> 
> Old Binutils:
>     <14>   DW_AT_name       : (indirect string, offset: 0x69):
> ../sysdeps/x86_64/crti.S
> 
> 2.36 Binutils:
>    <14>   DW_AT_name        : (strp) (offset: 0x69): ../sysdeps/x86_64/crti.S
>  
> Elfutils:
>           name                (strp) "../sysdeps/x86_64/crti.S"

I've got this point, makes sense. But I don't get why is that related to --wide option?
To be honest, the output of non-wide mode is longer and more verbose than --wide option
output:

$ readelf --debug-dump=info --wide /tmp/sample_struct.o | head -n20 | grep offset
    <11>   DW_AT_name        : (strp) (offset: 0x12d): mpers-m32/sample_struct.c
    <15>   DW_AT_comp_dir    : (strp) (offset: 0x89): /home/abuild/rpmbuild/BUILD/strace-5.10
    <20>   DW_AT_name        : (strp) (offset: 0x56): unsigned char

$ readelf --debug-dump=info /tmp/sample_struct.o | head -n20 | grep offset
    <11>   DW_AT_name        : (indirect string, offset: 0x12d): mpers-m32/sample_struct.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x89): /home/abuild/rpmbuild/BUILD/strace-5.10
    <20>   DW_AT_name        : (indirect string, offset: 0x56): unsigned char

...

>   Can the strace configure script be adapted to cope with both versions 
>   of readelf's output ?

I can report that to them. It's unpleasant that parsing would depend
on the version of binutils.

Thanks,
Martin
Comment 4 Martin Liska 2021-02-03 11:59:54 UTC
I've created a pull request and it seems that it would require a work:
https://github.com/strace/strace/pull/171
Comment 5 Martin Liska 2021-02-18 08:27:32 UTC
So I'm closing this as invalid.
Comment 6 Dmitry V. Levin 2021-02-18 11:17:58 UTC
Meanwhile, people started reporting that strace 5.11 does not build:
https://lists.strace.io/pipermail/strace-devel/2021-February/010406.html

I'll be redirecting them to this bug report.