[RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

I guess there was a slight improvement in the profile of
find_function_in_inferior. This causes a compilation failure on HP/UX.

As I was working on this file, I noticed a warning saying that we should
an extra pair of braces around the "&" expression, to avoid any
confusion. So I added it. I sometimes make silly mistakes, so I would
appreciate if somebody had a quick look, to make sure I did not screw
up.

This also gives me the opportunity to announce that the HP/UX target
is important for ACT, and that we will do the work necessary to keep
this port in good shape. My first goal for this platform is to make it
at least multiarch partial.

2002-10-30  Joel Brobecker  <brobecker@gnat.com>

        * hppa-tdep.c (find_function_in_inferior): Fix the declaration
        that caused a compilation error on HP/UX.
        (low_text_segment_addres): Fix a compilation warning.

Ok to apply?

Also, I am not sure about the 5.3 branch, I haven't pulled the sources
from this branch yet. But I will check this shortly and apply the fix
there if necessary (provided the change is approved, naturally).

Thanks,
-- 
Joel

[-- Attachment #2: hppa-tdep.c.diff --]
[-- Type: text/plain, Size: 1536 bytes --]

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.28
diff -c -3 -p -r1.28 hppa-tdep.c
*** hppa-tdep.c	24 Oct 2002 21:02:53 -0000	1.28
--- hppa-tdep.c	30 Oct 2002 07:57:35 -0000
*************** extern int hp_som_som_object_present;
*** 150,156 ****
  extern int exception_catchpoints_are_fragile;
  
  /* This is defined in valops.c. */
! extern struct value *find_function_in_inferior (char *);
  
  /* Should call_function allocate stack space for a struct return?  */
  int
--- 150,156 ----
  extern int exception_catchpoints_are_fragile;
  
  /* This is defined in valops.c. */
! extern struct value *find_function_in_inferior (const char *);
  
  /* Should call_function allocate stack space for a struct return?  */
  int
*************** static CORE_ADDR low_text_segment_addres
*** 300,306 ****
  static void
  record_text_segment_lowaddr (bfd *abfd, asection *section, void *ignored)
  {
!   if ((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY)
         == (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
        && section->vma < low_text_segment_address)
      low_text_segment_address = section->vma;
--- 300,306 ----
  static void
  record_text_segment_lowaddr (bfd *abfd, asection *section, void *ignored)
  {
!   if (((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
         == (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
        && section->vma < low_text_segment_address)
      low_text_segment_address = section->vma;

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

> 2002-10-30  Joel Brobecker  <brobecker@gnat.com>
> 
>         * hppa-tdep.c (find_function_in_inferior): Fix the declaration
>         that caused a compilation error on HP/UX.
>         (low_text_segment_addres): Fix a compilation warning.

Actually, I am replying to myself: the fix to find_function_in_inferior
works, but is pretty stupid. Better to remove the extern altogether,
since we get the definition directly from value.h (which caused the
compilation error in the first place). 

Sorry about that, I should not be working that late I suppose.

Here is a new patch, with a new ChangeLog:

2002-10-30  Joel Brobecker  <brobecker@gnat.com>

        * hppa-tdep.c (find_function_in_inferior): Remove this extern,
        as this is already provided by value.h, and was actually causing
        a compilation error due to a conflict in parameter type declaration
        due to a missing const keyword.
        (low_text_segment_addres): Fix a compilation warning.

It looks like the 5.3 branch has the same problem, so I'll fix it too
when I get approval for this patch.

Thanks,
-- 
Joel

[-- Attachment #2: hppa-tdep.c.diff --]
[-- Type: text/plain, Size: 1386 bytes --]

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.28
diff -c -3 -p -r1.28 hppa-tdep.c
*** hppa-tdep.c	24 Oct 2002 21:02:53 -0000	1.28
--- hppa-tdep.c	30 Oct 2002 08:24:34 -0000
*************** extern int hp_som_som_object_present;
*** 149,157 ****
  /* In breakpoint.c */
  extern int exception_catchpoints_are_fragile;
  
- /* This is defined in valops.c. */
- extern struct value *find_function_in_inferior (char *);
- 
  /* Should call_function allocate stack space for a struct return?  */
  int
  hppa_use_struct_convention (int gcc_p, struct type *type)
--- 149,154 ----
*************** static CORE_ADDR low_text_segment_addres
*** 300,306 ****
  static void
  record_text_segment_lowaddr (bfd *abfd, asection *section, void *ignored)
  {
!   if ((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY)
         == (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
        && section->vma < low_text_segment_address)
      low_text_segment_address = section->vma;
--- 297,303 ----
  static void
  record_text_segment_lowaddr (bfd *abfd, asection *section, void *ignored)
  {
!   if (((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
         == (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
        && section->vma < low_text_segment_address)
      low_text_segment_address = section->vma;

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 12:28:03AM -0800, Joel Brobecker wrote:
> > 2002-10-30  Joel Brobecker  <brobecker@gnat.com>
> > 
> >         * hppa-tdep.c (find_function_in_inferior): Fix the declaration
> >         that caused a compilation error on HP/UX.
> >         (low_text_segment_addres): Fix a compilation warning.
> 
> Actually, I am replying to myself: the fix to find_function_in_inferior
> works, but is pretty stupid. Better to remove the extern altogether,
> since we get the definition directly from value.h (which caused the
> compilation error in the first place). 
> 
> Sorry about that, I should not be working that late I suppose.
> 
> Here is a new patch, with a new ChangeLog:
> 
> 2002-10-30  Joel Brobecker  <brobecker@gnat.com>
> 
>         * hppa-tdep.c (find_function_in_inferior): Remove this extern,
>         as this is already provided by value.h, and was actually causing
>         a compilation error due to a conflict in parameter type declaration
>         due to a missing const keyword.
>         (low_text_segment_addres): Fix a compilation warning.
> 
> It looks like the 5.3 branch has the same problem, so I'll fix it too
> when I get approval for this patch.

Your patch is correct (and that's a serious warning, too... there was
an actual bug there).  With two sets of eyes this is OK to commit,
since HP/UX is currently marked as an OBSOLETE candidate.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Joel Brobecker]

> > 2002-10-30  Joel Brobecker  <brobecker@gnat.com>
> > 
> >         * hppa-tdep.c (find_function_in_inferior): Remove this extern,
> >         as this is already provided by value.h, and was actually causing
> >         a compilation error due to a conflict in parameter type declaration
> >         due to a missing const keyword.
> >         (low_text_segment_addres): Fix a compilation warning.
> 
> Your patch is correct (and that's a serious warning, too... there was
> an actual bug there).  With two sets of eyes this is OK to commit,
> since HP/UX is currently marked as an OBSOLETE candidate.

Thank you. I committed the change.

I checked the 5.3 branch, it is fine, build-wise. So nothing done
there.

-- 
Joel

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Elena Zannoni]

Joel Brobecker writes:
 > > 2002-10-30  Joel Brobecker  <brobecker@gnat.com>
 > > 
 > >         * hppa-tdep.c (find_function_in_inferior): Fix the declaration
 > >         that caused a compilation error on HP/UX.
 > >         (low_text_segment_addres): Fix a compilation warning.
 > 
 > Actually, I am replying to myself: the fix to find_function_in_inferior
 > works, but is pretty stupid. Better to remove the extern altogether,
 > since we get the definition directly from value.h (which caused the
 > compilation error in the first place). 
 > 

Yes, externs in .c files are flagged by the ARI, and should be removed
whenever one gets a chance. Are the Makefile dependencies on value.h in place?
(I always ask, I didn't check).

Seems ok to me.

Thanks for taking upon yourself the hppa cleanup task. It is really great news!

Elena


 > Sorry about that, I should not be working that late I suppose.
 > 
 > Here is a new patch, with a new ChangeLog:
 > 
 > 2002-10-30  Joel Brobecker  <brobecker@gnat.com>
 > 
 >         * hppa-tdep.c (find_function_in_inferior): Remove this extern,
 >         as this is already provided by value.h, and was actually causing
 >         a compilation error due to a conflict in parameter type declaration
 >         due to a missing const keyword.
 >         (low_text_segment_addres): Fix a compilation warning.
 > 
 > It looks like the 5.3 branch has the same problem, so I'll fix it too
 > when I get approval for this patch.
 > 
 > Thanks,
 > -- 
 > Joel
 > Index: hppa-tdep.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
 > retrieving revision 1.28
 > diff -c -3 -p -r1.28 hppa-tdep.c
 > *** hppa-tdep.c	24 Oct 2002 21:02:53 -0000	1.28
 > --- hppa-tdep.c	30 Oct 2002 08:24:34 -0000
 > *************** extern int hp_som_som_object_present;
 > *** 149,157 ****
 >   /* In breakpoint.c */
 >   extern int exception_catchpoints_are_fragile;
 >   
 > - /* This is defined in valops.c. */
 > - extern struct value *find_function_in_inferior (char *);
 > - 
 >   /* Should call_function allocate stack space for a struct return?  */
 >   int
 >   hppa_use_struct_convention (int gcc_p, struct type *type)
 > --- 149,154 ----
 > *************** static CORE_ADDR low_text_segment_addres
 > *** 300,306 ****
 >   static void
 >   record_text_segment_lowaddr (bfd *abfd, asection *section, void *ignored)
 >   {
 > !   if ((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY)
 >          == (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
 >         && section->vma < low_text_segment_address)
 >       low_text_segment_address = section->vma;
 > --- 297,303 ----
 >   static void
 >   record_text_segment_lowaddr (bfd *abfd, asection *section, void *ignored)
 >   {
 > !   if (((section->flags & (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
 >          == (SEC_ALLOC | SEC_LOAD | SEC_READONLY))
 >         && section->vma < low_text_segment_address)
 >       low_text_segment_address = section->vma;

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Joel Brobecker]

> Yes, externs in .c files are flagged by the ARI, and should be removed
> whenever one gets a chance. Are the Makefile dependencies on value.h in place?
> (I always ask, I didn't check).

Good question! I just checked, and the answer is yes. :-)

-- 
Joel

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 12:08:37AM -0800, Joel Brobecker wrote:
> This also gives me the opportunity to announce that the HP/UX target
> is important for ACT, and that we will do the work necessary to keep
> this port in good shape. My first goal for this platform is to make it
> at least multiarch partial.

Well!  Your timing is good; I've been waiting for a response from
Andrew for my last attempt to remove the HP/UX bits entirely.  But if
someone's going to do the work than I don't need to push for that.
This is good news.

Joel, is there any chance that ACT could provide outside GDB developers
with access to an HP/UX system?  That would make it much easier not to
break HP/UX (and to figure out what works on HP/UX now at all).

HP provides a number of Test Drive programs, which seem to cover
everything HP/Compaq has ever offered _except_ for HP/UX.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Andrew Cagney]

> On Wed, Oct 30, 2002 at 12:08:37AM -0800, Joel Brobecker wrote:
> 
>> This also gives me the opportunity to announce that the HP/UX target
>> is important for ACT, and that we will do the work necessary to keep
>> this port in good shape. My first goal for this platform is to make it
>> at least multiarch partial.
> 
> 
> Well!  Your timing is good; I've been waiting for a response from
> Andrew for my last attempt to remove the HP/UX bits entirely.  But if
> someone's going to do the work than I don't need to push for that.
> This is good news.
> 
> Joel, is there any chance that ACT could provide outside GDB developers
> with access to an HP/UX system?  That would make it much easier not to
> break HP/UX (and to figure out what works on HP/UX now at all).
> 
> HP provides a number of Test Drive programs, which seem to cover
> everything HP/Compaq has ever offered _except_ for HP/UX.

It does.  It's got:

HP-UX 11i 11.22 on i2000 Itanium  i2000 2@750MHz
HP-UX 11i 11.11 on rp2470 PA RISC rp2470 2@750MHz
HP-UX 11i 11.11 on rp5470 PA RISC rp5470 4@550MHz

but the two PA RISC machines are still down from the move.  ETA is 
apparently ``later today''.

Andrew

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Daniel Jacobowitz]

On Thu, Oct 31, 2002 at 12:32:20PM -0500, Andrew Cagney wrote:
> >On Wed, Oct 30, 2002 at 12:08:37AM -0800, Joel Brobecker wrote:
> >
> >>This also gives me the opportunity to announce that the HP/UX target
> >>is important for ACT, and that we will do the work necessary to keep
> >>this port in good shape. My first goal for this platform is to make it
> >>at least multiarch partial.
> >
> >
> >Well!  Your timing is good; I've been waiting for a response from
> >Andrew for my last attempt to remove the HP/UX bits entirely.  But if
> >someone's going to do the work than I don't need to push for that.
> >This is good news.
> >
> >Joel, is there any chance that ACT could provide outside GDB developers
> >with access to an HP/UX system?  That would make it much easier not to
> >break HP/UX (and to figure out what works on HP/UX now at all).
> >
> >HP provides a number of Test Drive programs, which seem to cover
> >everything HP/Compaq has ever offered _except_ for HP/UX.
> 
> It does.  It's got:
> 
> HP-UX 11i 11.22 on i2000 Itanium  i2000 2@750MHz
> HP-UX 11i 11.11 on rp2470 PA RISC rp2470 2@750MHz
> HP-UX 11i 11.11 on rp5470 PA RISC rp5470 4@550MHz
> 
> but the two PA RISC machines are still down from the move.  ETA is 
> apparently ``later today''.

Could you point me at information on HP's web site about these?  I
couldn't find it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Daniel Jacobowitz]

On Thu, Oct 31, 2002 at 12:35:27PM -0500, Daniel Jacobowitz wrote:
> On Thu, Oct 31, 2002 at 12:32:20PM -0500, Andrew Cagney wrote:
> > >On Wed, Oct 30, 2002 at 12:08:37AM -0800, Joel Brobecker wrote:
> > >
> > >>This also gives me the opportunity to announce that the HP/UX target
> > >>is important for ACT, and that we will do the work necessary to keep
> > >>this port in good shape. My first goal for this platform is to make it
> > >>at least multiarch partial.
> > >
> > >
> > >Well!  Your timing is good; I've been waiting for a response from
> > >Andrew for my last attempt to remove the HP/UX bits entirely.  But if
> > >someone's going to do the work than I don't need to push for that.
> > >This is good news.
> > >
> > >Joel, is there any chance that ACT could provide outside GDB developers
> > >with access to an HP/UX system?  That would make it much easier not to
> > >break HP/UX (and to figure out what works on HP/UX now at all).
> > >
> > >HP provides a number of Test Drive programs, which seem to cover
> > >everything HP/Compaq has ever offered _except_ for HP/UX.
> > 
> > It does.  It's got:
> > 
> > HP-UX 11i 11.22 on i2000 Itanium  i2000 2@750MHz
> > HP-UX 11i 11.11 on rp2470 PA RISC rp2470 2@750MHz
> > HP-UX 11i 11.11 on rp5470 PA RISC rp5470 4@550MHz
> > 
> > but the two PA RISC machines are still down from the move.  ETA is 
> > apparently ``later today''.
> 
> Could you point me at information on HP's web site about these?  I
> couldn't find it.

Found it this time.  I'm not sure what I was looking at last time,
then... thank you.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Andrew Cagney]

> It does.  It's got:
>> > 
>> > HP-UX 11i 11.22 on i2000 Itanium  i2000 2@750MHz
>> > HP-UX 11i 11.11 on rp2470 PA RISC rp2470 2@750MHz
>> > HP-UX 11i 11.11 on rp5470 PA RISC rp5470 4@550MHz
>> > 
>> > but the two PA RISC machines are still down from the move.  ETA is 
>> > apparently ``later today''.
> 
>> 
>> Could you point me at information on HP's web site about these?  I
>> couldn't find it.
> 
> 
> Found it this time.  I'm not sure what I was looking at last time,
> then... thank you.

To belatedly answer your question.  I originally found them when filling 
in the application form.  They were listed, just like all the others.

So, is there an ISO C compiler?

Andrew

Re: [RFA/Semi-obvious/5.3?] Fix compilation error in hppa-tdep.c

[Daniel Jacobowitz]

On Thu, Oct 31, 2002 at 04:18:35PM -0500, Andrew Cagney wrote:
> >It does.  It's got:
> >>> 
> >>> HP-UX 11i 11.22 on i2000 Itanium  i2000 2@750MHz
> >>> HP-UX 11i 11.11 on rp2470 PA RISC rp2470 2@750MHz
> >>> HP-UX 11i 11.11 on rp5470 PA RISC rp5470 4@550MHz
> >>> 
> >>> but the two PA RISC machines are still down from the move.  ETA is 
> >>> apparently ``later today''.
> >
> >>
> >>Could you point me at information on HP's web site about these?  I
> >>couldn't find it.
> >
> >
> >Found it this time.  I'm not sure what I was looking at last time,
> >then... thank you.
> 
> To belatedly answer your question.  I originally found them when filling 
> in the application form.  They were listed, just like all the others.
> 
> So, is there an ISO C compiler?

Yup.  And a copy of aCC, too...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer