Re: [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation

> > Actually, now that I think of it, a slightly cleaner approach would
> > probably be to extend the language vector to add a flag set to non-zero
> > for the languages that want nested-subprogram handling.  The only slight
> > issue is that the CU references the language enum, which means we need
> > to go from that enum to the language_defn to get access to the flag.
> 
> I think you should stick with a language test in the DWARF reader.

OK. Would the following kind of patch be what you have in mind?
Or would you prefer that the function simply take a language,
rather than a CU. Or actually no function at all?

2008-09-30  Joel Brobecker  <brobecker <at> adacore.com>

        * dwarf2read.c (dwarf2_handle_nested_subprograms_p): New function.
        (add_partial_subprogram): Replace check of Ada language by call
        to dwarf2_handle_nested_subprograms_p.
        (dwarf2_get_subprogram_pc_bounds, load_partial_dies): Likewise.

This is only just for comments, as there is still one question open:
For Ada, we store the symbols for nested subprograms in the global
context.  This allows us to break on these functions even when these
functions are not defined in the current context.  Do we want to do
the same with Pascal? Right now, I left this functionality out...
In Ada, we have found it to be extremely convenient to not have to
be inside the enclosing function before we can insert the breakpoint.
When there are ambiguities (say two functions have a nested subprogram
with the same name), the ambiguity can be resolved using the fully
qualified name.

[RFC] New language-method to print local symbol?

Hello,

This is another change that we made a while ago and that I wished
we started discussing earlier. Suppose we are stopped inside the
following procedure Foo (say at the "STOP" marker):

    procedure Foo is
       S : String := "1234";
       R : String renames S;
    begin
       S (S'First) := 'A';  -- STOP
    end Foo;

Here is what currently happens when a user does an "info locals":

    (gdb) info locals
    s = "1234"
    r = 72

Variable "R" is a renaming of S, and so R should have the same
value as "S"!. The problem is that renamings are encoded using
a bogus integer variable whose name tell us how to compute the
actual variable value.  For instance, if you look at exp_dbug.ads
in the gcc/ada sources, you'll see that the variable name has
an ___XR suffix followed by a codified string (XA means "dereference",
XR<field> means "select <field> component", etc). It's like a string-
ified version of a program.

Going back to our problem, the renaming above results in the following
actual variables to be defined:

[commit/Ada/obvious] Delete ada-lang.c:is_digits_suffix

This function is no longer used...

2008-09-30  Joel Brobecker  <brobecker <at> adacore.com>

        * ada-lang.c (is_digits_suffix): Delete unused function.

Tested on x86-linux by rebuilding GDB (and grep'ing the entire file).
Checked in.

-- 
Joel

Index: ada-lang.c
===================================================================
RCS file: /cvs/src/src/gdb/ada-lang.c,v
retrieving revision 1.176
diff -u -p -r1.176 ada-lang.c
--- ada-lang.c	30 Sep 2008 21:53:32 -0000	1.176
+++ ada-lang.c	1 Oct 2008 02:22:20 -0000
 <at>  <at>  -202,8 +202,6  <at>  <at>  static int equiv_types (struct type *, s

 static int is_name_suffix (const char *);

-static int is_digits_suffix (const char *str);
-
 static int wild_match (const char *, int, const char *);

 static struct value *ada_coerce_ref (struct value *);
 <at>  <at>  -5022,17 +5020,6  <at>  <at>  is_name_suffix (const char *str)

Re: [rfc] expose gdb values to python

Daniel Jacobowitz wrote:
> And I think it should have the same solution.  There's a default
> architecture for these cases (depending on how GDB was built).

Which is current_gdbarch, as far as I can tell. I'll provide a new version
of the patch which uses it when gdb.Value cannot get one from a nearby
type's objfile.
--

-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [rfc] expose gdb values to python

> +  gdb_test "python print 'result = ' + str(s\['a'\])" " = 3" "acess element inside struct using 8-bit
string name"
> +  gdb_test "python print 'result = ' + str(s\[u'a'\])" " = 3" "acess element inside struct using unicode name"

(Humpf, it's getting really hard sometimes to read these tests ).
Anyway, this forced me to have a heada..., I mean focus, and I noticed
a typo: "acess" -> "access".

--

-- 
Joel

Re: [rfc] expose gdb values to python

(Sorry I am participating so late in the discussion, but I am still
recovering from my summer, and only recently managed to learn some Python)

> The underlying question is what type model Value presents.  If a Value
> has a derived type, should we be able to access fields of the base
> class using v["f"]?  Or should we need v["Base"]["f"]?

My initial reaction to this question is that the Value object
should follow the same semantics as the debugger. For instance,
if class Foo inherits from class Bar, then any component of class
Bar should be directly visible from class Foo. So if X is Value
of type class Foo, and class Bar has a component named "Baz",
then I should be able to access that component with X["Baz"].

Better yet, I would love for the object to have one attribute
for each component that I could simply access using X.baz.
But I suspect that there is no way we can implement that without
having to compute the value of each component, which would be
quite wastful the vast majority of the time. Sigh, is it not
possible to lazy-initialize attributes?

--

-- 
Joel

RE: [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation

> -----Message d'origine-----
> De : Joel Brobecker [mailto:brobecker <at> adacore.com]
> Envoyé : Wednesday, October 01, 2008 3:16 AM
> À : Pierre Muller; gdb-patches <at> sourceware.org
> Objet : Re: [RFA/DWARF2] Handle nested subprograms in CU pc bound
> calculation
> 
> > > Actually, now that I think of it, a slightly cleaner approach would
> > > probably be to extend the language vector to add a flag set to
> > > non-zero for the languages that want nested-subprogram handling.
> > > The only slight issue is that the CU references the language enum,
> > > which means we need to go from that enum to the language_defn to
> get access to the flag.
> >
> > I think you should stick with a language test in the DWARF reader.
> 
> OK. Would the following kind of patch be what you have in mind?
> Or would you prefer that the function simply take a language, rather
> than a CU. Or actually no function at all?
> 
> 2008-09-30  Joel Brobecker  <brobecker <at> adacore.com>
> 
>         * dwarf2read.c (dwarf2_handle_nested_subprograms_p): New
> function.
>         (add_partial_subprogram): Replace check of Ada language by call
>         to dwarf2_handle_nested_subprograms_p.
>         (dwarf2_get_subprogram_pc_bounds, load_partial_dies): Likewise.

 This looks fine for me!

Re: [RFA/doco/Ada] Document special case for catchpoints on standard exceptions

> Date: Tue, 30 Sep 2008 14:10:46 -0700
> From: Joel Brobecker <brobecker <at> adacore.com>
> 
> This is the documentation part for the following change:
> http://www.sourceware.org/ml/gdb-patches/2008-09/msg00591.html

Thanks.

> OK to commit?

Yes, with one comment:

> +rather than the user-defined one.  For instance, assuming an exception
> +called  <at> code{Constraint_Error} is defined in package  <at> code{Pck}, then
> +the command to use to catch such exceptions is  <at> code{catch exception
> +Pck.Constraint_Error}.

The last part of the last sentence should be in  <at> kbd, not  <at> code, as it
is a command typed by the user on the keyboard.

Re: [commit/Ada] Special handling for predefined exceptions...

> Date: Tue, 30 Sep 2008 13:52:33 -0700
> From: Joel Brobecker <brobecker <at> adacore.com>
> 
> For Ada, we provide a command "catch exception [EXCEPTION_NAME]"
> that stops the execution when an exception is raised. If an exception
> name is specified in the command, then the debugger only stops when
> a specific exception is raised.  The matching of the exception is
> performed through an internal condition that looks like this:
> 
>     long_integer (e) = long_integer (&EXCEPTION_NAME)"
> 
> (where "e" is a parameter of the function where we inserted the
> catchpoint that contains a pointer to the exception data).  The way
> it works is: For every EXCEPTION_NAME, the compiler defines an entity
> whose name is EXCEPTION_NAME (fully qualified). So when we want to
> verify whether we have raised a given exception, we just verify that
> its address is the address of the symbol whose name is EXCEPTION_NAME.

I'd love to have all this info somewhere in gdbint.texinfo.

TIA

Re: [Core] [RFA/DWARF2] Handle nested subprograms in CU pc bound calculation

On 01 Oct 2008, at 09:42, Pierre Muller wrote:

> De : Joel Brobecker [mailto:brobecker <at> adacore.com]
>
>> This is only just for comments, as there is still one question open:
>> For Ada, we store the symbols for nested subprograms in the global
>> context.  This allows us to break on these functions even when these
>> functions are not defined in the current context.  Do we want to do  
>> the
>> same with Pascal?
>
>  I believe that, at least with the Free Pascal compiler and
> stabs debugging format (which is the format I worked on), all
> nested subprograms where also in the global context and thus
> I would not mind to do the same for pascal language.
>
>  I must confess that I stopped working for the Free Pascal compiler
> more or less when the dwarf debugging format was added, and I almost  
> don't
> know
> anything about that format...
>  The only thing that I can tell, is that last time I checked
> Free Pascal (version 2.2.0 windows 32bit target) with -gw (dwarf  
> debugging
> format)
> I still got lots of errors while trying to load the compiler inside  
> gdb :(

At least under Mac OS X, FPC with dwarf works fairly well. I believe