public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Zoran Zaric <Zoran.Zaric@amd.com>
To: Simon Marchi <simon.marchi@polymtl.ca>, gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH 01/13] gdb/dwarf: change read_loclist_index complaints into errors
Date: Thu, 28 Jan 2021 15:17:25 +0000	[thread overview]
Message-ID: <6d8498e3-8580-e537-d5b4-4dcb041bb7a9@amd.com> (raw)
In-Reply-To: <20210120053925.142862-2-simon.marchi@polymtl.ca>

> From: Simon Marchi <simon.marchi@efficios.com>
> 
> Unlike read_rnglists_index, read_loclist_index uses complaints when it
> detects an inconsistency (a DW_FORM_loclistx value without a
> .debug_loclists section or an offset outside of the section).  I really
> think they should be errors, since there's no point in continuing if
> this situation happens, we will likely segfault or read garbage.
> 

Makes sense.

Although unless I misunderstand something, isn't the difference here 
that the error will actually throw an exception and therefore stop 
reading of the compilation unit if not the whole object file debug 
information?

If this is the case, then considering the difference in usage between 
the two, having a wrong loclist information can still provide a correct 
line table information, but having a wrong rnglist information in my 
mind creates a more serious issue.

On the other hand, how much can one trust in the information correctness 
if either of those are wrong.

  reply	other threads:[~2021-01-28 15:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-20  5:39 [PATCH 00/13] DWARF 5 rnglists & loclists fixes (PR 26813) Simon Marchi
2021-01-20  5:39 ` [PATCH 01/13] gdb/dwarf: change read_loclist_index complaints into errors Simon Marchi
2021-01-28 15:17   ` Zoran Zaric [this message]
2021-01-28 15:42     ` Simon Marchi
2021-02-25 19:20       ` Tom Tromey
2021-01-20  5:39 ` [PATCH 02/13] gdb/dwarf: fix bound check in read_rnglist_index Simon Marchi
2021-01-28 15:22   ` Zoran Zaric
2021-01-20  5:39 ` [PATCH 03/13] gdb/dwarf: add missing bound check to read_loclist_index Simon Marchi
2021-01-20  5:39 ` [PATCH 04/13] gdb/dwarf: remove unnecessary check in read_{rng, loc}list_index Simon Marchi
2021-01-20  5:39 ` [PATCH 05/13] gdb/dwarf: few fixes for handling DW_FORM_{rng, loc}listx Simon Marchi
2021-01-28 15:30   ` [PATCH 05/13] gdb/dwarf: few fixes for handling DW_FORM_{rng,loc}listx Zoran Zaric
2021-01-20  5:39 ` [PATCH 06/13] gdb/dwarf: read correct rnglist/loclist header in read_{rng, loc}list_index Simon Marchi
2021-01-28 15:39   ` [PATCH 06/13] gdb/dwarf: read correct rnglist/loclist header in read_{rng,loc}list_index Zoran Zaric
2021-01-28 15:49     ` Simon Marchi
2021-01-28 15:54       ` Zoran Zaric
2021-01-20  5:39 ` [PATCH 07/13] gdb/dwarf: read DW_AT_ranges value as unsigned in partial_die_info::read Simon Marchi
2021-01-28 15:41   ` Zoran Zaric
2021-01-28 15:51     ` Simon Marchi
2021-01-20  5:39 ` [PATCH 08/13] gdb/testsuite: add .debug_rnglists tests Simon Marchi
2021-01-28 16:24   ` Zoran Zaric
2021-01-20  5:39 ` [PATCH 09/13] gdb/testsuite: DWARF assembler: add context parameters to _location Simon Marchi
2021-01-28 16:30   ` Zoran Zaric
2021-01-20  5:39 ` [PATCH 10/13] gdb/testsuite: add .debug_loclists tests Simon Marchi
2021-01-28 16:52   ` Zoran Zaric
2021-01-28 17:47     ` Simon Marchi
2021-01-29 10:13       ` Zoran Zaric
2021-01-29 15:57         ` Simon Marchi
2021-01-29 16:58           ` Zoran Zaric
2021-01-29 17:37             ` Simon Marchi
2021-01-20  5:39 ` [PATCH 11/13] gdb/dwarf: split dwarf2_cu::ranges_base in two Simon Marchi
2021-01-20  5:39 ` [PATCH 12/13] gdb/dwarf: make read_{loc, rng}list_index return sect_offset Simon Marchi
2021-02-25 19:26   ` Tom Tromey
2021-01-20  5:39 ` [PATCH 13/13] gdb/testsuite: add test for .debug_{rng, loc}lists section without offset array Simon Marchi
2021-02-02 15:43 ` [PATCH 00/13] DWARF 5 rnglists & loclists fixes (PR 26813) Simon Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d8498e3-8580-e537-d5b4-4dcb041bb7a9@amd.com \
    --to=zoran.zaric@amd.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@efficios.com \
    --cc=simon.marchi@polymtl.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).