Re: build-ids, .debug_sup and other IDs

2021-03-02 Thread Tom Tromey
Frank> (Does dwz'd dwarf5 even work on gdb Frank> etc. now?) It doesn't, this thread started because I sent a patch to change gdb to read .debug_sup. This hasn't landed yet. Tom

Re: build-ids, .debug_sup and other IDs

2021-03-02 Thread Tom Tromey
>> But, this seemed a bit weird. What if both appear and they are >> different? Then a single API isn't so great -- you want to check the ID >> corresponding to whatever was in the original file. Frank> If both appear and are different, can we characterize the elf file as Frank> malformed? Not

Re: build-ids, .debug_sup and other IDs

2021-02-24 Thread Tom Tromey
> "Mark" == Mark Wielaard writes: >> This patch adds support for this to gdb. It is largely >> straightforward, I think, though one oddity is that I chose not to >> have this code search the system build-id directories for the >> supplementary file. My feeling was that, while it makes sense

Re: [PATCH v2] Fix leb128 reading

2020-10-30 Thread Tom Tromey
> "Mark" == Mark Wielaard writes: Mark> Looks good. While reviewing I did try out some extra corner cases that Mark> I added (see attached). It also shows that some values can have Mark> multiple representations. I added them to your commit before I pushed Mark> it. Hope you don't mind. Seem

Re: [PATCH] Fix bug in read_3ubyte_unaligned_inc

2020-10-29 Thread Tom Tromey
>>>>> "Mark" == Mark Wielaard writes: Mark> On Sat, Oct 24, 2020 at 03:05:55PM -0600, Tom Tromey wrote: Mark> Clearly DW_FORM_strx3 and DW_FORM_addrx3 aren't used much Mark> (given that it is an index value between larger than 65536). >> >>

[PATCH v2] Fix leb128 reading

2020-10-28 Thread Tom Tromey
implementation-defined cast to convert to signed. Signed-off-by: Tom Tromey --- .gitignore| 1 + ChangeLog | 4 ++ libdw/ChangeLog | 10 +++ libdw/dwarf_getlocation.c | 5 +- libdw/memory-access.h | 42 ++-- tests/ChangeLog

Re: [PATCH] Fix leb128 reading

2020-10-26 Thread Tom Tromey
>> In this patch, I chose to try to handle weird leb128 encodings by >> preserving their values when possible; or returning the maximum value >> on overflow. It isn't clear to me that this is necessarily the best >> choice. Mark> I think it is a good thing to accept "padded" leb128 numbers, but M

Re: [PATCH] Fix bug in read_3ubyte_unaligned_inc

2020-10-24 Thread Tom Tromey
Mark> Clearly DW_FORM_strx3 and DW_FORM_addrx3 aren't used much Mark> (given that it is an index value between larger than 65536). I don't even really see the need for a 3-byte form. Anyway if it helps, gdb gets this wrong too -- gdb always uses little-endian, which seems wrong, but I didn't know

[PATCH] Fix leb128 reading

2020-10-23 Thread Tom Tromey
Tom Tromey + + * .gitignore: Add /tests/leb128. + 2020-10-01 Frank Ch. Eigler PR25461 diff --git a/libdw/ChangeLog b/libdw/ChangeLog index 8b0b583a..23081c12 100644 --- a/libdw/ChangeLog +++ b/libdw/ChangeLog @@ -1,3 +1,14 @@ +2020-10-23 Tom Tromey + + PR

[PATCH] Fix bug in read_3ubyte_unaligned_inc

2020-10-23 Thread Tom Tromey
The read_3ubyte_unaligned_inc macro calls read_2ubyte_unaligned, but it should call read_3ubyte_unaligned. Signed-off-by: Tom Tromey --- libdw/ChangeLog | 5 + libdw/memory-access.h | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/libdw/ChangeLog b/libdw/ChangeLog

Re: [PATCH] readelf: Decode DW_AT_discr_list block attributes.

2019-05-10 Thread Tom Tromey
> "Mark" == Mark Wielaard writes: Mark> Decode DW_AT_descr_list blocks using the DW_DSC values. Mark> This requires knowing the signedness of the discriminant. Mark> Which means the attr_callback function needs access to the Mark> parent DIE. Pass the whole DIE path, plus the current level. M

Re: [PATCH] readelf: Print DIE offset in attribute reading error messages.

2017-11-21 Thread Tom Tromey
> "Mark" == Mark Wielaard writes: Mark> This has been really useful to debug some DWARF format issues, but it Mark> could be even more useful. Since we know the attribute name and form Mark> (or we would have generated an error earlier) add those to the error Mark> message too. Thanks for do