[Bug tools/22250] New: readelf should support --dwarf-start and --dwarf-depth

[tromey at sourceware dot org]

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

Bug ID: 22250
   Summary: readelf should support --dwarf-start and --dwarf-depth
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: tools
  Assignee: unassigned at sourceware dot org
  Reporter: tromey at sourceware dot org
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

objdump supports --dwarf-start and --dwarf-depth options.
--dwarf-start specifies the DIE at which to begin dumping.
--dwarf-depth specifies how many levels down to print; if
there are more levels it just prints "...", like:

 <0><2174>: Abbrev Number: 1 (DW_TAG_compile_unit)
<2175>   DW_AT_producer: (indirect string, offset: 0x0): clang LLVM
(rustc version 1.20.0 (f3d6973f4 2017-08-27))
<2179>   DW_AT_language: 28 (Unknown: 1c)
<217b>   DW_AT_name: (indirect string, offset: 0x1621):
/checkout/src/libstd/lib.rs
<217f>   DW_AT_stmt_list   : 0x9f2
<2183>   DW_AT_comp_dir: (indirect string, offset: 0x163d):
/checkout/obj
<2187>   DW_AT_low_pc  : 0x0
<218f>   DW_AT_ranges  : 0x2be80
 <1><2193>: ...


These are handy for investigating large files with dwarf-mode that
is in binutils.

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

[Bug tools/22250] readelf should support --dwarf-start and --dwarf-depth

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey  ---
(In reply to Mark Wielaard from comment #1)

> Which properties of the above are important to you?
> Is the given selection mechanism of which DIEs to print the most convenient?
> Is it important to suppress header printing?
> Since this really is about printing something after an offset from the start
> of a section, should it be extended to other debug sections?

I implemented this stuff in objdump to support browsing DWARF in Emacs.
The Emacs mode dumps the "outline" of the DWARF into a buffer, then
you can click on a '...' to get more data there.  That explains why
header suppression is done...

However lately I wanted to use this with eu-readelf to track down that
bad DWARF bug: https://github.com/rust-lang/rust/issues/44412
In that case I wouldn't care so much about the headers.

But really it would be nice to have it all so that I could port the
Emacs mode to use eu-readelf.

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

[Bug tools/23100] New: dwarflint -vs- DW_AT_alignment

[tromey at sourceware dot org]

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

Bug ID: 23100
   Summary: dwarflint -vs- DW_AT_alignment
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: tools
  Assignee: unassigned at sourceware dot org
  Reporter: tromey at sourceware dot org
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

dwarflint should issue a warning if DW_AT_alignment is not a power of 2.

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

[Bug tools/23100] dwarflint -vs- DW_AT_alignment

[tromey at sourceware dot org]

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

--- Comment #1 from Tom Tromey  ---
It should also check other constraints, like that it is a constant
and that it is a positive integer.

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

[Bug tools/24509] New: eu-readelf does not know how to dissect DW_AT_discr_list

[tromey at sourceware dot org]

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

Bug ID: 24509
   Summary: eu-readelf does not know how to dissect
DW_AT_discr_list
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: tools
  Assignee: unassigned at sourceware dot org
  Reporter: tromey at sourceware dot org
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

Consider the Ada test case in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935#c2.

Compiling to a .o and then using eu-readelf will yield something
like:

...
 [6b]variant  abbrev: 5
 discr_list   (block1) 7 byte block: 01 01 ff ff ff ff
07

discr_list has a specified structure, and it would be nice
if eu-readelf could dump it more verbosely.

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

[Bug tools/24509] eu-readelf does not know how to dissect DW_AT_discr_list

[tromey at sourceware dot org]

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

--- Comment #2 from Tom Tromey  ---
Here's one that uses both ranges and discrete elements:

package Rng is

   type Rec (I : Integer) is record
  case I is
 when Positive =>
C : Character;
case I is
   when 1..15 | 17 | 23 =>
  null;
   when others =>
  N : Natural;
end case;
 when others =>
S : String (1 .. 10);
  end case;
   end record;

   R : Rec (1);

end Rng;



And here's one that uses unsigned types:

package Urng is

   type Unsigned is mod 65536;
   type Rec (I : Unsigned) is record
  case I is
 when 17 | 23 | 32768..65535 =>
null;
 when others =>
S : String (1 .. 10);
  end case;
   end record;

   R : Rec (1);

end Urng;

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

[Bug tools/24509] eu-readelf does not know how to dissect DW_AT_discr_list

[tromey at sourceware dot org]

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

--- Comment #3 from Tom Tromey  ---
To check for negative values, I think you can add another
clause, here's what I did:

package Rng is

   type Rec (I : Integer) is record
  case I is
 when Positive =>
C : Character;
case I is
   when 1..15 | 17 | 23 =>
  null;
   when others =>
  N : Natural;
end case;
 when -52..-1 =>
Q: Natural;
 when others =>
S : String (1 .. 10);
  end case;
   end record;

   R : Rec (1);

end Rng;


The proposed patch does not handle this properly:

 [9f]variant  abbrev: 5
 discr_list   (block1) range: 76-127

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

[Bug tools/24509] eu-readelf does not know how to dissect DW_AT_discr_list

[tromey at sourceware dot org]

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

--- Comment #5 from Tom Tromey  ---
FWIW the output looks reasonable to me now.  Thanks for doing this!

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

[Bug tools/24550] New: eu-readelf does not know about DW_AT_GNU_bias

[tromey at sourceware dot org]

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

Bug ID: 24550
   Summary: eu-readelf does not know about DW_AT_GNU_bias
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: tools
  Assignee: unassigned at sourceware dot org
  Reporter: tromey at sourceware dot org
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

The Ada compiler can emit DW_AT_GNU_bias in some situations.

Here is "tt.adb":

with Text_IO; use Text_IO;
procedure Tt is
   type Small is range -7 .. -4;
   for Small'Size use 2;
   Y : Small := -5;

  type Repeat_Count_T is range 1 .. 2 ** 6;
  for Repeat_Count_T'Size use 6;
  X : Repeat_Count_T := 64;
begin
  Put_Line (X'Image);
  Put_Line (Y'Image);
end Tt;


Compile with

gcc -fgnat-encodings=minimal -g -c tt.adb

gdb's dwarf2.def says:

/* Biased integer extension.
   See https://gcc.gnu.org/wiki/DW_AT_GNU_bias .  */
DW_TAG (DW_AT_GNU_bias, 0x2305)

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

[Bug tools/24550] eu-readelf does not know about DW_AT_GNU_{bias,numerator,denumerator}

[tromey at sourceware dot org]

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

--- Comment #2 from Tom Tromey  ---
(In reply to Mark Wielaard from comment #1)

> Could you help me with creating gnat examples that compile and show their
> usage?

For bias, the above works.

> If I try to compile your example I get two warnings:
> 
> tt.adb:4:04: warning: size clause forces biased representation for "Small"
> tt.adb:8:03: warning: size clause forces biased representation for
> "Repeat_Count_T"
> 
> Are those expected?

Yes, though I don't know the rationale.

The numerator and denominator attributes are used for fixed-point types.
There is a test for this in g...@github.com:pmderodat/dwarf-ada-testsuite.git

murgatroyd. readelf -wi tests/fixedpoint/foo.o |grep DW_AT_GNU_[dn]
<229>   DW_AT_GNU_numerator: 1
<22a>   DW_AT_GNU_denominator: 30
<237>   DW_AT_GNU_numerator: 0
<238>   DW_AT_GNU_denominator: 0


> Also the subranges come out as:
[...]
> There are three things that surprised me about this.
> First that the byte_size is 1, are these types really using a full byte and
> not 2 or 6 bits?

I'm not totally sure what is going on here.  Maybe the type needs to be
used in a packed record to see it actually shrink?  I will see if I can write
a test for this.

> And second that the bias is on the subrange_type and not the base_type. Is
> that intended?

Yes, the bias only applies to subrange types, not the base type.

> Finally, why is the last type signed?

I think that's the default.  You have to request an unsigned based type
explicitly, like:

   type Byte is mod 256;
   type Repeat_Count_T is new Byte range 1 .. 2 ** 6;

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

[Bug tools/24550] eu-readelf does not know about DW_AT_GNU_{bias,numerator,denumerator}

[tromey at sourceware dot org]

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

--- Comment #3 from Tom Tromey  ---
> > There are three things that surprised me about this.
> > First that the byte_size is 1, are these types really using a full byte and
> > not 2 or 6 bits?
> 
> I'm not totally sure what is going on here.  Maybe the type needs to be
> used in a packed record to see it actually shrink?  I will see if I can write
> a test for this.

Thanks for noticing this.  I think the DWARF is incorrect here in a few
ways -- I am going to update the internal bug about it to get it fixed.

Meanwhile here is the updated test case I am using

--  Copyright 2019 Free Software Foundation, Inc.
--
--  This program is free software; you can redistribute it and/or modify
--  it under the terms of the GNU General Public License as published by
--  the Free Software Foundation; either version 3 of the License, or
--  (at your option) any later version.
--
--  This program is distributed in the hope that it will be useful,
--  but WITHOUT ANY WARRANTY; without even the implied warranty of
--  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
--  GNU General Public License for more details.
--
--  You should have received a copy of the GNU General Public License
--  along with this program.  If not, see .

procedure Bias is
   type Small is range -7 .. -4;
   for Small'Size use 2;
   Y : Small := -5;
   Y1 : Small := -7;

   type Byte is mod 256;
   type Repeat_Count_T is new Byte range 1 .. 2 ** 6;
   for Repeat_Count_T'Size use 6;
   X : Repeat_Count_T := 64;
   X1 : Repeat_Count_T := 1;

   type Char_Range is range 65 .. 68;
   for Char_Range'Size use 2;
   Cval : Char_Range := 65;

   type SomePackedRecord is record
  R: Small;
  S: Small;
   end record;
   pragma Pack (SomePackedRecord);
   SPR : SomePackedRecord := (R => -4, S => -5);

   type Packed_Array is array (1 .. 3) of Small;
   pragma pack (Packed_Array);
   A : Packed_Array := (-7, -5, -4);

begin
   null;
end Bias;

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

[Bug tools/24550] eu-readelf does not know about DW_AT_GNU_{bias,numerator,denumerator}

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey  ---
BTW some of the oddities encountered might be good for dwarflint...

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

[Bug tools/24799] New: dwarflint could check .debug_names

[tromey at sourceware dot org]

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

Bug ID: 24799
   Summary: dwarflint could check .debug_names
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: tools
  Assignee: unassigned at sourceware dot org
  Reporter: tromey at sourceware dot org
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

It would be handy if dwarflint checked that .debug_names was
complete and correct according to the rules in the DWARF
standard; though perhaps augmented with enumeration constants,
see this thread:
http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2018-April/004433.html

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

[Bug debuginfod/25502] New: debuginfod client should default to XDG cache

[tromey at sourceware dot org]

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

Bug ID: 25502
   Summary: debuginfod client should default to XDG cache
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: debuginfod
  Assignee: unassigned at sourceware dot org
  Reporter: tromey at sourceware dot org
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

The debuginfod client defaults its cache to:

static const char *cache_default_name = ".debuginfod_client_cache";
static const char *cache_path_envvar = DEBUGINFOD_CACHE_PATH_ENV_VAR;
[...]

  if (getenv(cache_path_envvar))
strcpy(cache_path, getenv(cache_path_envvar));
  else
{
  if (getenv("HOME"))
sprintf(cache_path, "%s/%s", getenv("HOME"), cache_default_name);
  else
sprintf(cache_path, "/%s", cache_default_name);
}



That is, $HOME/.debuginfod_client_cache in the usual setup.

I think it would be better if this followed the XDG
base directory spec instead. 
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

In this case, this text applies:

 $XDG_CACHE_HOME defines the base directory relative to which user specific
non-essential data files should be stored. If $XDG_CACHE_HOME is either not set
or empty, a default equal to $HOME/.cache should be used. 

I would suggest a subdirectory of this, like .../debuginfod_client

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

[Bug debuginfod/25502] debuginfod client should default to XDG cache

[tromey at sourceware dot org]

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

--- Comment #3 from Tom Tromey  ---
(In reply to Mark Wielaard from comment #2)
> What about the Default database file? Currently $HOME/.debuginfod.sqlite
> 
> Should that go under $XDG_DATA_HOME/debuginfod/ ?
> And then probably not as hidden file?

If the file can be deleted and then re-created without difficulty,
then it should go in the cache directory as well.

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

[Bug debuginfod/25502] debuginfod client should default to XDG cache

[tromey at sourceware dot org]

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

--- Comment #6 from Tom Tromey  ---
> I think it's fair to default to XDG_CACHE_HOME since if the database is
> particularly important to a user they'll probably just specify its location
> like Mark said.

FWIW I only really care about the behavior on the client side.
I think for a server making a database, it would be reasonable to just
require the user specify some location; or default to ".".  IMO there's
no real reason to use some XDG directory in this situation.

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

[Bug tools/30772] New: dwarflint checking for specification recursion

[tromey at sourceware dot org via Elfutils-devel]

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

Bug ID: 30772
   Summary: dwarflint checking for specification recursion
   Product: elfutils
   Version: unspecified
Status: NEW
  Severity: normal
  Priority: P2
 Component: tools
  Assignee: unassigned at sourceware dot org
  Reporter: tromey at sourceware dot org
CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

This idea comes from this thread:

https://sourceware.org/pipermail/gdb-patches/2023-August/201655.html

The idea is that if a DIE refers to itself via a chain
of DW_AT_specification (or the other ways a DIE can refer
to another), then dwarflint ought to warn, as recursion like
this is never valid.

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

[Bug libdw/26773] sleb128 values near INT64_MAX/MIN not correctly read

[tromey at sourceware dot org via Elfutils-devel]

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

--- Comment #1 from Tom Tromey  ---
I looked at this a little today.

In addition to this bug, I think the _unchecked variants
have another bug; namely they do:

  const size_t max = len_leb128 (int64_t) - 1;

This limits the number of bytes read-- but it seems like
it maybe ought to read until the first byte without the
high bit set.

FWIW gdb seems to rely on implementation-defined behavior
here.  It does all the sleb work in an unsigned type
and then casts it to signed on return.

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

[Bug tools/29150] Would be useful to have a filter in eu-readelf like --name=

[tromey at sourceware dot org via Elfutils-devel]

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

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at sourceware dot org

--- Comment #1 from Tom Tromey  ---
dwgrep can do this and way, way more.

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