Re: add file I/O support when debugging an embedded target via jtag

> Date: Sun, 31 Aug 2008 12:41:40 +0100
> From: Bart Veer <bartv <at> ecoscentric.com>
> CC: gdb-patches <at> sourceware.org
> 
> In the meantime, please find below an updated version of the patch
> which incorporates your documentation comments and which applies to
> current CVS.

Thanks, the documentation part is okay.

Re: [rfc][00/37] Eliminate builtin_type_ macros

From: Mark Kettenis <mark.kettenis <at> xs4all.nl>
Date: Mon, 1 Sep 2008 00:18:16 +0200 (CEST)

> I've probably had one piwo too many at this point, but can we please
> stop this Linux [x/zillion] crap?  You can't seriously pretend there
> are really 37 independent diffs that people would want to review
> and/or test can you?

Why is it crap to split up a large harder to review (and bisect)
change into bite size (easier to review and later bisect) independant
pieces?  And why is it purely labelled as "a Linux thing" to split up
a large patch this way?  I've seen this submission technique used in
many other projects.

If a reviewer doesn't have time to review the whole bit, they can
choose to look at one a few or even just one of them, when it is
split up like this.

What if later there is a regression and someone tries to bisect
through this change?  If we have just one huge one it's harder to
figure out which of the 37 parts caused the problem, whereas if
we could bisect to one of these 37 pieces, we'd know precisely which
part added the regression.

That is just smart development as far as I can see.

The response I am seeing seems like a negative knee jerk reaction to
me.  I post sets of 50 patches at a time frequently for some of my
work, and it eases the reviewer burdon tremendously.

Re: [rfc][15/37] Eliminate builtin_type_ macros: Dereferencing of integer types

>>>>> "Ulrich" == Ulrich Weigand <uweigand <at> de.ibm.com> writes:

Ulrich> GDB allows to dereference an integer type, treating it as if
Ulrich> it were an "int *".

Ulrich> It might make sense to check for which languages this extension
Ulrich> is actually useful, and remove it from the rest.

Ulrich> 	* jv-lang.c (evaluate_subexp_java): Likewise.

FWIW -- I couldn't come up with a situation where this extension makes
sense for Java.  I'm certain I have never used it while debugging Java
code.

Tom

[patch] Fix crash on reading gcc HEAD Fortran module

Hi,

with the current gcc snapshot this testcase
MODULE m
  integer :: varx
END MODULE m
USE m, a=>varx
end

crashes gdb HEAD on `break 2' with:
dwarf2read.c:2766: internal-error: process_die: Assertion `die->child == NULL' failed.
A problem internal to GDB has been detected,

While it still cannot reach the imported variables it at least no longer
crashes now.  Notified by Tobias Burnus.

Regards,
Jan

2008-09-01  Jan Kratochvil  <jan.kratochvil <at> redhat.com>

	Stay compatible after the GCC PR fortran/29635 fix.
	* dwarf2read.c (process_die <DW_TAG_imported_module>): Accept (ignored)
	child DIEs.  Only COMPLAINT for non-Fortran languages.

--- gdb/dwarf2read.c	29 Aug 2008 17:06:05 -0000	1.278
+++ gdb/dwarf2read.c	1 Sep 2008 12:56:19 -0000
 <at>  <at>  -2763,7 +2763,10  <at>  <at>  process_die (struct die_info *die, struc
 	 Fortran case, so we'll have to replace this gdb_assert if

Re: [patch] Fix crash on reading gcc HEAD Fortran module

On Mon, Sep 01, 2008 at 03:02:12PM +0200, Jan Kratochvil wrote:
> 2008-09-01  Jan Kratochvil  <jan.kratochvil <at> redhat.com>
> 
> 	Stay compatible after the GCC PR fortran/29635 fix.
> 	* dwarf2read.c (process_die <DW_TAG_imported_module>): Accept (ignored)
> 	child DIEs.  Only COMPLAINT for non-Fortran languages.

This patch is mostly OK; please complain about children in
DW_TAG_imported_declaration even in Fortran (see the comment above
your change).

--

-- 
Daniel Jacobowitz
CodeSourcery

[RFA/powerpc] Add handling for stack-check sequences in prologue

Hello,

On PPC targets, the debugger fails to unwind past some stack-check
sequences. The attached patch should fix that. I have double-checked
with Eric Botcazou to make sure that all possible cases are
caught... Roughly:

1) A small number of probes:
         stw 0, -<some immediate>(1) repeated any (small) number of times...

2) A probing loop:
         addi 12,1,-<some immediate>
         lis 0,-<some immediate>
         [possibly ori 0,0,<some immediate>]
         add 0,12,0
         cmpw 0,12,0
         beq 0,<disp>
         addi 12,12,-<some immediate>
         stw 0,0(12)
         b <disp>
         [possibly one last probe: stw 0,<some immediate>(12)]

3) No probe; instead, a comparizon between the stack size
     limit (saved in a run-time global variable) and the current stack
     pointer:

        addi 0,1,-<some immediate>
        lis 12,__gnat_stack_limit <at> ha
        lwz 12,__gnat_stack_limit <at> l(12)
        twllt 0,12

Re: [patch] Fix crash on reading gcc HEAD Fortran module

On Mon, 01 Sep 2008 17:29:56 +0200, Daniel Jacobowitz wrote:
> please complain about children in DW_TAG_imported_declaration even in
> Fortran (see the comment above your change).

Originally I expected these complaints are just for detected DWARF violations:
	_("Offset %d out of bounds for DW_AT_ranges attribute"),
But they are produced even just for unsupported DWARF features:
	complaint (&symfile_complaints, _("unsupported tag: '%s'"),

Therefore it should always complain to any such DW_TAG_imported_* tag as they
are always at least unsupported.  (And it does not matter if some of their
forms with or without children are invalid for DWARF or not.)

[ approval requested ]

Thanks,
Jan

2008-09-01  Jan Kratochvil  <jan.kratochvil <at> redhat.com>

	Stay compatible after the GCC PR fortran/29635 fix.
	* dwarf2read.c (process_die <DW_TAG_imported_module>)
	(process_die <DW_TAG_imported_module>): Do not assert anything about
	these unsupported tags.

--- ./gdb/dwarf2read.c	29 Aug 2008 17:06:05 -0000	1.278
+++ ./gdb/dwarf2read.c	1 Sep 2008 16:35:17 -0000
 <at>  <at>  -2760,10 +2760,10  <at>  <at>  process_die (struct die_info *die, struc
 	 information contained in these.  DW_TAG_imported_declaration

[RFA/testsuite] stack check

Test that GDB is able to get a correct backtrace when the application
is compiled with -fstack-check. Related to:
http://sourceware.org/ml/gdb-patches/2008-09/msg00005.html

2008-09-01  Jerome Guitton  <guitton <at> adacore.com>

	* (stack-checking.c, stack-checking.exp): New testcase.

OK to apply?

Thanks,
- Jerome

# Copyright 2008 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

Re: [RFA/testsuite] stack check

Jerome Guitton (guitton <at> adacore.com):

> 
> Test that GDB is able to get a correct backtrace when the application
> is compiled with -fstack-check.

BTW, I have a similar testcase in PPC assembly. It checks that the
different stack-checking sequences that GCC may emit for this target
are understood by GDB. It could be merged into
gdb.arch/powerpc-aix-prologue.exp. If it is of any help, I'll be happy
to post it in this list.

Thanks,
- Jerome

Re: [rfc][00/37] Eliminate builtin_type_ macros

Mark Kettenis wrote:

> I've probably had one piwo too many at this point, but can we please
> stop this Linux [x/zillion] crap?  You can't seriously pretend there
> are really 37 independent diffs that people would want to review
> and/or test can you?

Actually, the patches *do* touch mostly independent areas of GDB,
and I'd expect different maintainers to want to review only some
of them.  I've spent some effort to try to separate out functional
changes, in the hope of making review simpler ...

As to *testing*, I agree that having to apply 37 patches in sequence
is a pain, which is why I sent -in addition to the broken-out series-
a single cumulative patch as well.

In the end, this is simply a large set of changes (the cumulative patch
is 8000 lines, the broken-out patches total 10000 lines) spread out
across many parts of GDB (the patch set touches 97 files) -- if you have
suggestions how to present a change like this in a way that's easier to
review, those would certainly be welcome.

Bye,
Ulrich

--

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand <at> de.ibm.com