This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] arm reversible : <phase_2_complete>

On 3 November 2011 18:38, Tom Tromey <> wrote:
>>>>>> "Petr" == Petr HluzÃn <> writes:
> Petr> The guideline - which I think Tom was reffering to - is that
> Petr> impossible states and coding bugs in gdb should trigger assertions
> Petr> however user's input (no matter how malformed) should trigger warning
> Petr> or error messages.
> Yes, I think that rule makes the most sense.
> Petr> Some situations are difficult to decide whether they are trigger-able
> Petr> by user input or not.
> Petr> If my code is not coded or intended to handle such situations I prefer
> Petr> to kill the process (or whatever are assertions configured to do) and
> Petr> get feedback from user.
> Petr> I am not familiar with GDB customs, though. Tom?
> I think crashing gdb should be limited to "can't happen" scenarios
> arising from the internal logic.

How strong is the "can't happen" requirement? Is programmer required
to prove the assertion cannot be triggered? The difficulty in general
case would be equivalent to proving a code is bug-free - i.e. it is
impossible. At my job we try to verify an assumption until we have a
sort-of-proof or the search becomes difficult and no clue/indication
to the contrary has been found yet.
I am asking because GDB code contains surprisingly few assertions.

> Tripping across an unrecognized instruction or the like should just
> result in an ordinary gdb error -- something the user can reasonably
> recover from.
> If the error message is informative enough about what went wrong, it
> will result in a bug report :-)

Well, when user gets a message "assertion failed" (and the user had
not messed with gdb sources) then the user knows its a bug in gdb. The
user does not have to understand what code broke - application
programmers generally do not have the knowledge anyway (symbols, ELF
internals, debugging hooks etc).

Anyway, the patch had used assertions correctly because expression
`bits (X, 21, 24)' yields value in range 0..15 for any value of X - no
matter how bogus X value. Yes, all 2^32 values map to 0..15. The
assertions satisfy the guideline. (This is not even the hard-to-prove
case I was speculating above.)

Petr Hluzin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]