Re: rolling 5.3.92 tomorrow

Re: rolling 5.3.92 tomorrow

[Michael Elizabeth Chastain]

5.3.91 was fine in my test bed.  I'm spinning the tests right now, including
gdb_6_0-branch 2003-09-11 07:19:23 UTC.  I'll have a report in 12-18 hours.

Michael C

Re: rolling 5.3.92 tomorrow

[Michael Elizabeth Chastain]

 > http://sources.redhat.com/gdb/bugs/1367
 > readline/doc/history.0 deleted

I haven't done any more looking since my last comment.  :(
Is this really a show-stopper for releasing gdb?

 > http://sources.redhat.com/gdb/bugs/857
 > GDB contains intl/ droppings
 > Did/can micahelC's hacks fix this?

I didn't touch this, but the same place that I fixed gdb/708
would be a good place to hack in a few more 'rm' statements.
It's in file src-release, rule do-proto-toplev.

I will look at 857 tonight.

Michael C

Re: rolling 5.3.92 tomorrow

[Michael Elizabeth Chastain]

drow> The only other issue I know of is that Mark's per-objfile-data patch,
drow> and my fix for the assertion failures in Java, aren't on the branch
drow> yet.  Should we move those patches over?

I would love to have the Java assertion patch on the branch.
It's a very localized patch -- it just changes the order of
two tests, really.  It's easy to verify that it can't break
anything.  And on the upside, it fixes a crash bug.

Michael C

rolling 5.3.92 tomorrow

[Andrew Cagney]

FYI,

Assuming that there aren't any more crasher bugs and the current ones 
are in, I'll roll up another draft 6.0 tomorrow.  Hopefully, after that, 
I'll be able to roll out the real thing early next week.

Andrew

Re: rolling 5.3.92 tomorrow

[Daniel Jacobowitz]

On Thu, Sep 11, 2003 at 10:22:35AM -0400, Andrew Cagney wrote:
> FYI,
> 
> Assuming that there aren't any more crasher bugs and the current ones 
> are in, I'll roll up another draft 6.0 tomorrow.  Hopefully, after that, 
> I'll be able to roll out the real thing early next week.

Great.  I have one patch left to check in (ctx->in_reg), I'll do that
today.

The only other issue I know of is that Mark's per-objfile-data patch,
and my fix for the assertion failures in Java, aren't on the branch
yet.  Should we move those patches over?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: rolling 5.3.92 tomorrow

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Sep 11, 2003 at 10:22:35AM -0400, Andrew Cagney wrote:
 > > FYI,
 > > 
 > > Assuming that there aren't any more crasher bugs and the current ones 
 > > are in, I'll roll up another draft 6.0 tomorrow.  Hopefully, after that, 
 > > I'll be able to roll out the real thing early next week.
 > 
 > Great.  I have one patch left to check in (ctx->in_reg), I'll do that
 > today.
 > 
 > The only other issue I know of is that Mark's per-objfile-data patch,
 > and my fix for the assertion failures in Java, aren't on the branch
 > yet.  Should we move those patches over?
 > 

I don't see why not. They didn't cause any problems in the trunk.

elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: rolling 5.3.92 tomorrow

[Daniel Jacobowitz]

On Thu, Sep 11, 2003 at 02:02:50PM -0400, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > On Thu, Sep 11, 2003 at 10:22:35AM -0400, Andrew Cagney wrote:
>  > > FYI,
>  > > 
>  > > Assuming that there aren't any more crasher bugs and the current ones 
>  > > are in, I'll roll up another draft 6.0 tomorrow.  Hopefully, after that, 
>  > > I'll be able to roll out the real thing early next week.
>  > 
>  > Great.  I have one patch left to check in (ctx->in_reg), I'll do that
>  > today.
>  > 
>  > The only other issue I know of is that Mark's per-objfile-data patch,
>  > and my fix for the assertion failures in Java, aren't on the branch
>  > yet.  Should we move those patches over?
>  > 
> 
> I don't see why not. They didn't cause any problems in the trunk.

I've done this now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: rolling 5.3.92 tomorrow

[Andrew Cagney]

Checking/editing the bug database:

 > http://sources.redhat.com/gdb/bugs/1367
 > readline/doc/history.0 deleted

needs to be investigated

 > http://sources.redhat.com/gdb/bugs/857
 > GDB contains intl/ droppings

Did/can micahelC's hacks fix this?

 > http://sources.redhat.com/gdb/bugs/378
 > ``GNU/Linux'' ``Linux kernel''

The ARI's complaining about regressions in ppc-linux-tdep.c

Andrew

Re: rolling 5.3.92 tomorrow

[Jim Blandy]

Andrew Cagney <ac131313@redhat.com> writes:
>  > http://sources.redhat.com/gdb/bugs/378
>  > ``GNU/Linux'' ``Linux kernel''
> 
> The ARI's complaining about regressions in ppc-linux-tdep.c

I think this is because I forgot to apply this patch to the 60 branch,
too.  I'll do so now.

2003-06-24  Jim Blandy  <jimb@redhat.com>

	* ppc-linux-tdep.c: More "Linux" -> "GNU/Linux".

*** gdb/ppc-linux-tdep.c.~1.36.~	2003-06-24 18:06:07.000000000 -0500
--- gdb/ppc-linux-tdep.c	2003-06-24 18:09:02.000000000 -0500
***************
*** 731,737 ****
  }
  
  
! /* If DESC is the address of a 64-bit PowerPC Linux function
     descriptor, return the descriptor's entry point.  */
  static CORE_ADDR
  ppc64_desc_entry_point (CORE_ADDR desc)
--- 731,737 ----
  }
  
  
! /* If DESC is the address of a 64-bit PowerPC GNU/Linux function
     descriptor, return the descriptor's entry point.  */
  static CORE_ADDR
  ppc64_desc_entry_point (CORE_ADDR desc)
***************
*** 894,915 ****
  }
  
  
! /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR) on PPC64 Linux.
  
     Usually a function pointer's representation is simply the address
!    of the function. On Linux on the 64-bit PowerPC however, a function
!    pointer is represented by a pointer to a TOC entry. This TOC entry
!    contains three words, the first word is the address of the
!    function, the second word is the TOC pointer (r2), and the third
!    word is the static chain value.  Throughout GDB it is currently
!    assumed that a function pointer contains the address of the
!    function, which is not easy to fix.  In addition, the conversion of
!    a function address to a function pointer would require allocation
!    of a TOC entry in the inferior's memory space, with all its
!    drawbacks.  To be able to call C++ virtual methods in the inferior
!    (which are called via function pointers), find_function_addr uses
!    this function to get the function address from a function
!    pointer.  */
  
  /* Return real function address if ADDR (a function pointer) is in the data
     space and is therefore a special function pointer.  */
--- 894,915 ----
  }
  
  
! /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR) on PPC64 GNU/Linux.
  
     Usually a function pointer's representation is simply the address
!    of the function. On GNU/Linux on the 64-bit PowerPC however, a
!    function pointer is represented by a pointer to a TOC entry. This
!    TOC entry contains three words, the first word is the address of
!    the function, the second word is the TOC pointer (r2), and the
!    third word is the static chain value.  Throughout GDB it is
!    currently assumed that a function pointer contains the address of
!    the function, which is not easy to fix.  In addition, the
!    conversion of a function address to a function pointer would
!    require allocation of a TOC entry in the inferior's memory space,
!    with all its drawbacks.  To be able to call C++ virtual methods in
!    the inferior (which are called via function pointers),
!    find_function_addr uses this function to get the function address
!    from a function pointer.  */
  
  /* Return real function address if ADDR (a function pointer) is in the data
     space and is therefore a special function pointer.  */
***************
*** 929,935 ****
  }
  
  
! /* On 64-bit PowerPC Linux, the ELF header's e_entry field is the
     address of a function descriptor for the entry point function, not
     the actual entry point itself.  So to find the actual address at
     which execution should begin, we need to fetch the function's entry
--- 929,935 ----
  }
  
  
! /* On 64-bit PowerPC GNU/Linux, the ELF header's e_entry field is the
     address of a function descriptor for the entry point function, not
     the actual entry point itself.  So to find the actual address at
     which execution should begin, we need to fetch the function's entry
***************
*** 1062,1068 ****
    
    if (tdep->wordsize == 8)
      {
!       /* Handle PPC64 Linux function pointers (which are really
           function descriptors).  */
        set_gdbarch_convert_from_func_ptr_addr
          (gdbarch, ppc64_linux_convert_from_func_ptr_addr);
--- 1062,1068 ----
    
    if (tdep->wordsize == 8)
      {
!       /* Handle PPC64 GNU/Linux function pointers (which are really
           function descriptors).  */
        set_gdbarch_convert_from_func_ptr_addr
          (gdbarch, ppc64_linux_convert_from_func_ptr_addr);

Re: rolling 5.3.92 tomorrow

[Andrew Cagney]

> FYI,
> 
> Assuming that there aren't any more crasher bugs and the current ones are in, I'll roll up another draft 6.0 tomorrow.  Hopefully, after that, I'll be able to roll out the real thing early next week.

Well that didn't happen, I'll try again in a few hours or tomorrow ...

> I would love to have the Java assertion patch on the branch.
> It's a very localized patch -- it just changes the order of
> two tests, really.  It's easy to verify that it can't break
> anything.  And on the upside, it fixes a crash bug.

which Java assertion patch?

Andrew

Re: rolling 5.3.92 tomorrow

[Daniel Jacobowitz]

On Sun, Sep 14, 2003 at 07:50:36PM -0400, Andrew Cagney wrote:
> >FYI,
> >
> >Assuming that there aren't any more crasher bugs and the current ones are 
> >in, I'll roll up another draft 6.0 tomorrow.  Hopefully, after that, I'll 
> >be able to roll out the real thing early next week.
> 
> Well that didn't happen, I'll try again in a few hours or tomorrow ...
> 
> >I would love to have the Java assertion patch on the branch.
> >It's a very localized patch -- it just changes the order of
> >two tests, really.  It's easy to verify that it can't break
> >anything.  And on the upside, it fixes a crash bug.
> 
> which Java assertion patch?

I moved it over this morning - the one for dwarf2-frame.c.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer