headers
Joel Brobecker | 1 Dec 2004 03:42
Favicon

[RFA/alpha] Fetch register from the right frame

Hello,

Trying to switch to gdb-6.3 on alpha-tru64, we noticed the following
problem:

    (gdb) bt
    #0  0x000003ff8057d43c in __hstTransferRegistersPC ()
       from /usr/shlib/libpthread.so
    #1  0x000003ff8056e8e4 in __osTransferContext ()
       from /usr/shlib/libpthread.so
    #2  0x000003ff80560c30 in __dspDispatch () from /usr/shlib/libpthread.so
    #3  0x000003ff80560178 in __cvWaitPrim () from /usr/shlib/libpthread.so
    #4  0x000003ff8055da9c in __pthread_cond_wait ()
       from /usr/shlib/libpthread.so
    #5  0x000000012002cf50 in system.tasking.rendezvous.wait_for_call ()
        at s-tasren.adb:6
    #6  0x00000001200296ec in system.tasking.rendezvous.accept_trivial ()
        at s-tasren.adb:6
    #7  0x000000012001e204 in task_switch.callee (<_task>=Cannot access memory at address 0x28
    ) at task_switch.adb:29
    warning: Previous frame inner to this frame (corrupt stack?)

The two symptoms of the same problem are:

  . "<_task>=Cannot access memory at address 0x28" at frame #7
  . warning: Previous frame inner to this frame (corrupt stack?)

The callstack is missing the following two frames:

    #8  0x0000000120027cfc in system.tasking.stages.task_wrapper ()
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joel Brobecker | 1 Dec 2004 04:03
Favicon

Re: [RFA] Improve "start" command for Ada

Hello Elena,

Thanks for the your review.

On Sun, Nov 28, 2004 at 09:08:21PM -0500, Elena Zannoni wrote:
> Joel Brobecker writes:
>  > Ping? (doco already approved by Eli)
>  > 
>  > On Thu, Oct 21, 2004 at 02:09:51PM -0700, Joel Brobecker wrote:
>  > > 2004-10-20  Joel Brobecker  <brobecker <at> gnat.com>
>  > > 
>  > >         * doc/observer.texi (executable_changed): New observer.
>  > >         * symtab.c: Include "observer.h".
>  > >         (find_main_name): New function.
>  > >         (main_name): If name_of_main is unset, then compute it
>  > >         using find_main_name.
>  > >         (symtab_observer_executable_changed): New function.
>  > >         (_initialize_symtab): Attach executable_changed observer.
>  > >         * exec.c: Include "observer.h".
>  > >         (exec_file_attach): Emit executable_changed notification.
>  > >         * symfile.c: Include "observer.h".
>  > >         (reread_symbols): Send an executable_changed if appropriate.
>  > >         * Makefile.in (exec.o): Add dependency on observer.h.
>  > >         (symfile.o): Likewise.
>  > >         (symtab.o): Likewise.
>  > > 
>  > > Tested on x86-linux. Still fixes 1 FAIL in gdb.ada/null_record.exp.
>  > > 
> 
> We need a testcase where the name of the executable is changed, and
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joel Brobecker | 1 Dec 2004 04:05
Favicon

Re: [RFA/dwarf2] Use SYMBOL_SEARCH_NAME to set type name

>  > > 2004-10-22  Joel Brobecker  <brobecker <at> gnat.com>
>  > >         
>  > >         From Paul Hilfinger <hilfinger <at> gnat.com>
>  > >         * dwarf2read.c (new_symbol): Use SYMBOL_SEARCH_NAME rather than
>  > >         SYMBOL_NATURAL_NAME to set type names.

> Sigh, this is a hack on top af another.  Unfortunately the initial
> review of the symtab Ada changes wasn't helpful.  I have no choice but
> to let this go in for now, however, please, start thinking of a way to
> get rid of those special cases in SYMBOL_blah_NAME.  Making those
> become part of the language vector comes to mind.

OK, I see Paul, who is the one who knows most about these symbol names
issues, has already answered, so I won't comment on that (I didn't have
much to say anyway :-).

> Can you come up with a test case for gdb.ada that shows the problem,
> and is cured by this patch?

Yes, I think so. I will commit a testcase and then commit this change.
Thanks for your review.

--

-- 
Joel
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 1 Dec 2004 04:20
Favicon

Re: [RFA/testsuite/ada] Put testcase code in own directory

Michael,

> nothing for or against this.  However it's strategic decision - one for 
> MichaelC - should for package like languages such as ada (and for that 
> matter java) we have a directory per test? :-)

In reviewing this patch, I see that there are some pieces that I forgot
to include. So the patch can not be accepted as is.

However, would you mind telling us what you think about the principle?
If you want my opinion, I am strongly attached to the idea of having
one subdirectory per testcase. The current approach used for C where
you can pretty much always have all the code for one testcase stored
in one .c file simply does not work for Ada. With GNAT, you need the
filename to match the name of the unit, and you need to have one and
only one unit per file[1]. Most testcases will involve at least 3 files,
one containing the main procedure (that one compilation unit), plus
a .ads file containing the spec of a package, plus a .adb file
containing the body of a package. Some testcases will use many
more files than this (we have one testcase internally that creates
something like 200 packages).

For maintenance reasons, I really feel that one subdirectory per
testcase is the way to go.

I hope you'll agree with me, in which case I'll work on producing
a new iteration of this patch, complete this time.

> >2004-11-08  Joel Brobecker  <brobecker <at> gnat.com>
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joel Brobecker | 1 Dec 2004 04:21
Favicon

Re: [RFA/tru64] Compute bfd_section for minimal symbols

Ping?

    http://sources.redhat.com/ml/gdb-patches/2004-11/msg00201.html

On Wed, Nov 10, 2004 at 10:01:39AM -0800, Joel Brobecker wrote:
> 2004-11-10  Joel Brobecker  <brobecker <at> gnat.com>
> 
>         * mdebugread.c (record_minimal_symbol): New procedure.
>         (parse_partial_symbols): Use record_minimal_symbol to record
>         the new minimal symbols instead of prim_record_minimal_symbol
>         and prim_record_minimal_symbol_and_info.

--

-- 
Joel
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 1 Dec 2004 04:31
Favicon

Re: [RFA/dwarf2] Fix name of include psymtabs, avoid duplicates

>  > > 2004-10-16  Joel Brobecker  <brobecker <at> gnat.com>
>  > > 
>  > >         * dwarf2read.c (dwarf_decode_lines): Use the complete filename
>  > >         when creating include psymtabs.
>  > > 
>  > > Tested on x86-linux, no regression.
>  > > OK to apply?
> 
> Yes, after you add the test, which should fail before and pass after
> your patch.

I'll see what I can come up with, and commit the patch once a testcase
for it has been added.

Thanks for the review,
--

-- 
Joel
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 1 Dec 2004 05:31
Favicon

[RFA/alpha] Fix problem loading core files

I noticed that GDB is no longer able to load the registers from a core
file:

        (gdb) core core
 OK  -> Core was generated by `crash'.
 OK  -> Program terminated with signal 6, Aborted.
 !?! -> Register  not found in core file.

That lead me to a couple of issues. First, in fetch_osf_core_registers()
in alpha-nat.c; we have an array named core_reg_mapping[ALPHA_NUM_REGS]
which value is statically defined (minus a #if ... #else ... #endif
 twist):

  static int const core_reg_mapping[ALPHA_NUM_REGS] =
  {
#ifdef NCF_REGS
#define EFL NCF_REGS
    CF_V0, CF_T0, CF_T1, CF_T2, CF_T3, CF_T4, CF_T5, CF_T6,
    [...].

The problem is that ALPHA_NUM_REGS has been incremented on 2003-01-31:

        * alpha-nat.c (REGISTER_PTRACE_ADDR): Merge into ...
        (register_addr): ... here.  Support ALPHA_UNIQUE_REGNUM.
        (fetch_elf_core_registers): Support ALPHA_UNIQUE_REGNUM.
        * alpha-tdep.c (alpha_register_name): Add "unique".
        * alpha-tdep.h (ALPHA_NUM_REGS): Increment.
        (ALPHA_UNIQUE_REGNUM): New.
        * config/alpha/nm-linux.h (ALPHA_UNIQUE_PTRACE_ADDR): New.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Daniel Jacobowitz | 1 Dec 2004 05:54

Re: [RFA/testsuite/ada] Put testcase code in own directory

On Tue, Nov 30, 2004 at 07:20:21PM -0800, Joel Brobecker wrote:
> Michael,
> 
> > nothing for or against this.  However it's strategic decision - one for 
> > MichaelC - should for package like languages such as ada (and for that 
> > matter java) we have a directory per test? :-)
> 
> In reviewing this patch, I see that there are some pieces that I forgot
> to include. So the patch can not be accepted as is.
> 
> However, would you mind telling us what you think about the principle?
> If you want my opinion, I am strongly attached to the idea of having
> one subdirectory per testcase. The current approach used for C where
> you can pretty much always have all the code for one testcase stored
> in one .c file simply does not work for Ada. With GNAT, you need the
> filename to match the name of the unit, and you need to have one and
> only one unit per file[1]. Most testcases will involve at least 3 files,
> one containing the main procedure (that one compilation unit), plus
> a .ads file containing the spec of a package, plus a .adb file
> containing the body of a package. Some testcases will use many
> more files than this (we have one testcase internally that creates
> something like 200 packages).
> 
> For maintenance reasons, I really feel that one subdirectory per
> testcase is the way to go.
> 
> I hope you'll agree with me, in which case I'll work on producing
> a new iteration of this patch, complete this time.

Well, it seems reasonable to me.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel Brobecker | 1 Dec 2004 05:57
Favicon

Re: [RFA/alpha] Fix problem loading core files

[With the patch, this time. Thanks Daniel!]

I noticed that GDB is no longer able to load the registers from a core
file:

        (gdb) core core
 OK  -> Core was generated by `crash'.
 OK  -> Program terminated with signal 6, Aborted.
 !?! -> Register  not found in core file.

That lead me to a couple of issues. First, in fetch_osf_core_registers()
in alpha-nat.c; we have an array named core_reg_mapping[ALPHA_NUM_REGS]
which value is statically defined (minus a #if ... #else ... #endif
 twist):

  static int const core_reg_mapping[ALPHA_NUM_REGS] =
  {
#ifdef NCF_REGS
#define EFL NCF_REGS
    CF_V0, CF_T0, CF_T1, CF_T2, CF_T3, CF_T4, CF_T5, CF_T6,
    [...].

The problem is that ALPHA_NUM_REGS has been incremented on 2003-01-31:

        * alpha-nat.c (REGISTER_PTRACE_ADDR): Merge into ...
        (register_addr): ... here.  Support ALPHA_UNIQUE_REGNUM.
        (fetch_elf_core_registers): Support ALPHA_UNIQUE_REGNUM.
        * alpha-tdep.c (alpha_register_name): Add "unique".
        * alpha-tdep.h (ALPHA_NUM_REGS): Increment.
        (ALPHA_UNIQUE_REGNUM): New.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Jacobowitz | 1 Dec 2004 06:10

Re: [RFA/alpha] Fetch register from the right frame

On Tue, Nov 30, 2004 at 06:42:20PM -0800, Joel Brobecker wrote:

> I tracked the problem to alpha_heuristic_frame_prev_register():
> Basically, after having verified that the register we'd like to fetch
> has not been saved in by the next frame, we try to fetch the value
> of the register inside the next frame. But instead, what we do, is
> that we actually fetch the value of the register for the frame
> *following* the next frame. Oups!

The patch seems OK to me.  This is consistent with what other targets
do, also.

I have to stare at this a little bit each time... prev_register takes a
NEXT_FRAME argument.  It is unwinding from THIS frame - which is not
one of its arguments - using THIS_CACHE.  That's because a frame is
responsible for its own ID and the previous frame's registers.  By the
time prev_register is called we have THIS frame available, but passing
it wouldn't do much good.

> 2004-11-30  Joel Brobecker  <brobecker <at> gnat.com>
> 
>         * alpha-tdep.c (alpha_heuristic_frame_prev_register): Fetch
>         the register value from the correct frame.
> 
> Tested on alpha-tru64 5.1, fixes the problem above, no regression
> in the testsuite.
> 
> OK to apply?

Yes.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane