Is anyone using the HP compilers on PA-RISC with FSF GDB?

I've forwarded comments that I made in response to
Daniel's message to
Randolph.

Forwarded message:
> From dave Wed Aug 2 11:45:40 EDT 2006
> Subject: Re: [Fwd: Is anyone using the HP compilers on
PA-RISC with FSF GDB?]
> To: randolphtausq.org (Randolph Chung)
> Date: Wed, 2 Aug 2006 11:45:40 -0400 (EDT)
> From: "John David Anglin" <davehiauly1>
> In-Reply-To: <44D019E7.2040405tausq.org> from
"Randolph Chung" at Aug 2, 2006 11:20:07 am
> X-Mailer: ELM [version 2.4 PL25]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Length: 2025      
> 
> > I have a question, though, which I think I've
asked before.  GCC on
> > HP/UX uses stabs, so only requires basic SOM
support from GDB.  That
> 
> There have been requests for ELF debug support.  The
main issue as
> far as I can see is the lack of named sections and
where to put stuff.
> 
> > should be in decent shape still.  But the stuff
read by hpread.c is
> > only generated by the HP compilers (cc and aCC).
> > 
> > - Are these compilers still important for C?
> > - Are these compilers still important for C++?
> 
> Oh, I'm sure these compilers are still important to
some people.
> However, I don't see the need to maintain support for
the debug
> format generated by these compilers.  There's no debug
info in any
> of the system libraries, so this capability doesn't
help development
> of open source applications under HP-UX.
> 
> I should also say that access to HP compilers is
necessary to
> maintain this code.  Thus, it really can only be done
by HP.  If
> they don't maintain it, then it should be removed.
> 
> > I have not heard from any users of the FSF GDB
with the HP compilers in
> > a long time; for HP-specific features, I suspect
more people use HP's
> > WDB fork of GDB.  If no one is using the HP
support, I would like to
> > remove it from the next release of GDB.
> 
> The HP compilers are quite stable, so I think WDB
should be adequate.
> HP can always update WDB if necessary.  I don't think
it's likely that
> HP will change their compilers on PA-RISC to provide
ISO compliance.
> It would require significant changes to the runtime.

I.e., the current HP C and aCC compilers are in a holding
pattern except
for bug fixes.

> On the otherhand, GCC C, C++, Ada and Java are now
working quite well
> on PA-RISC for both Linux and HP-UX.  So, I would
suggest that we need
> to focus support in these areas.  Of course, I'm a bit
biased ;)

Dave
-- 
J. David Anglin                                 
dave.anglinnrc-cnrc.gc.ca
National Research Council of Canada              (613)
990-0752 (FAX: 952-6602)

On Wed, Aug 02, 2006 at 03:16:56PM -0400, John David Anglin
wrote:
> > > I have a question, though, which I think
I've asked before.  GCC on
> > > HP/UX uses stabs, so only requires basic SOM
support from GDB.  That
> > 
> > There have been requests for ELF debug support. 
The main issue as
> > far as I can see is the lack of named sections and
where to put stuff.

Do you mean DWARF-2 here?  If so, I completely agree.  It
seems like
SOM has some named sections - at least we're managing to
get objdump to
tell me there's a GDB_STRINGS section - so I don't know
what the
problem is.

> > > should be in decent shape still.  But the
stuff read by hpread.c is
> > > only generated by the HP compilers (cc and
aCC).
> > > 
> > > - Are these compilers still important for C?
> > > - Are these compilers still important for
C++?
> > 
> > Oh, I'm sure these compilers are still important
to some people.
> > However, I don't see the need to maintain support
for the debug
> > format generated by these compilers.  There's no
debug info in any
> > of the system libraries, so this capability
doesn't help development
> > of open source applications under HP-UX.
> > 
> > I should also say that access to HP compilers is
necessary to
> > maintain this code.  Thus, it really can only be
done by HP.  If
> > they don't maintain it, then it should be
removed.

At one point in the past, the Compaq testdrive systems
offered aCC.  I
don't think they do any more though.

Thanks for the response, Dave - if you don't think we need
to hold on
to aCC support, then I doubt anyone else will either. 
However, there's
no need to rush; I'll wait for at least a few weeks, in
case anyone
else has comments, and then come back to this if no one
does.

> > On the otherhand, GCC C, C++, Ada and Java are now
working quite well
> > on PA-RISC for both Linux and HP-UX.  So, I would
suggest that we need
> > to focus support in these areas.  Of course, I'm
a bit biased ;)

I'd be much happier working on support for GCC  
Especially if that
means DWARF-2 debug information!

-- 
Daniel Jacobowitz
CodeSourcery

> > > There have been requests for ELF debug
support.  The main issue as
> > > far as I can see is the lack of named
sections and where to put stuff.
> 
> Do you mean DWARF-2 here?  If so, I completely agree. 
It seems like

Oops, yes DWARF-2.

> SOM has some named sections - at least we're managing
to get objdump to
> tell me there's a GDB_STRINGS section - so I don't
know what the
> problem is.

Yes, SOM has named spaces and subspaces.  However, we backed
away from
using named sections in the SOM port a few years ago because
there were 
issues with them in collect2's processing.  Section symbols
and name
truncation, when using HP nm, caused problems with
constructors/destructors.

There's no problem in generating named subspaces to hold
the various
flavors of DWARF-2 debug info.  However, there is some
dependence
on the presence of named section support in GCC's DWARF-2
output code
as I recall.  That's the only issue that needs a little
thinking.

Dave
-- 
J. David Anglin                                 
dave.anglinnrc-cnrc.gc.ca
National Research Council of Canada              (613)
990-0752 (FAX: 952-6602)

On Wed, Aug 02, 2006 at 03:21:56PM -0400, Daniel Jacobowitz
wrote:
> On Wed, Aug 02, 2006 at 03:16:56PM -0400, John David
Anglin wrote:
> > > > I have a question, though, which I think
I've asked before.  GCC on
> > > > HP/UX uses stabs, so only requires basic
SOM support from GDB.  That
> > > 
> > > There have been requests for ELF debug
support.  The main issue as
> > > far as I can see is the lack of named
sections and where to put stuff.
> 
> Do you mean DWARF-2 here?  If so, I completely agree. 
It seems like
> SOM has some named sections - at least we're managing
to get objdump to
> tell me there's a GDB_STRINGS section - so I don't
know what the
> problem is.

> I'd be much happier working on support for GCC  
Especially if that
> means DWARF-2 debug information!

I've attached a couple of preliminary patches to GCC and
binutils
to implement DWARF2 debugging on the HP-UX RA-RISC SOM
target.  It
builds and I don't see any testsuite regressions so far. 
What I need
to know is whether GDB can successfully access the DWARF2
subspaces
and whether this actually works.

What I did was to enable the target define to create named
sections.
Then, I disabled use of named sections for functions, data,
profiling,
etc.  I confirmed with a full bootstrap and check that named
sections
weren't being used.  This part was easy.

Next, I added the code to create the DWARF2 sections
(subspaces) and
enabled DWARF2.  This is when I discovered that GAS didn't
support
label differences in different segments.  Ok, so I define
DIFF_EXPR_OK
in tc-hppa.h in spite of the comment that says it doesn't
work.  I
think I may have fixed this problem last fall when I
corrected data
fixups.

Then, I discover that HP ld can't do unaligned symbol
differences.
Well, I knew that but I didn't realize that dwarf2out.c
needs this
capability.  The HP linker can do unaligned fixups for
absolute
addresses.  I see that defining
have_multiple_function_sections to
true in dwarf2out.c causes it to use absolute references. 
The
code in dwarf2out.c can't detect our unnamed subspace
changes in
the $TEXT$ space.  Even with a single function we have
multiple text
subspaces, so I decided to just provide a mechanism to
initialize
have_multiple_function_sections to true.

So, the fundamental problem is that the HP linker can't
handle
unaligned symbol differences.  I haven't detected any
further problems
with this in the test build, but I don't understand the
DWARF
machinary sufficiently well to know if there are other
circumstances
where unaligned symbol differences might occur.

There are minor problems with the section flags printed by
objdump.
However, odump tells me they are correct.  I tried to setup
the
DWARF2 debug space and subspaces in a manner similar to
HP's debug
format.  I at first used the $DEBUG$ space but discovered
that HP
also uses this space for their debug information.  Putting
the
DWARF2 info in this space confuses pxdb, so I changes the
name to
$DWARF_DEBUG$.

Thoughts?

Dave
-- 
J. David Anglin                                 
dave.anglinnrc-cnrc.gc.ca
National Research Council of Canada              (613)
990-0752 (FAX: 952-6602)
Index: defaults.h
============================================================
=======
--- defaults.h	(revision 116106)
+++ defaults.h	(working copy)
 -355,6
+355,14 
 #endif
 #endif
 
+/* If a compilation always places functions in more than
one section,
+   then you may need to define
HAVE_MULTIPLE_FUNCTION_SECTIONS to TRUE
+   in your target configuration file in order to support
the DWARF2 debug
+   format.  This avoids unaligned symbol differences from
being emitted.  */
+#ifndef HAVE_MULTIPLE_FUNCTION_SECTIONS
+#define HAVE_MULTIPLE_FUNCTION_SECTIONS false
+#endif
+
 /* If we have named section and we support weak symbols,
then use the
    .jcr section for recording java classes which need to be
registered
    at program start-up time.  */
Index: dwarf2out.c
============================================================
=======
--- dwarf2out.c	(revision 116106)
+++ dwarf2out.c	(working copy)
 -3904,7
+3904,8 
 static GTY(()) unsigned line_info_table_in_use;
 
 /* True if the compilation unit places functions in more
than one section.  */
-static GTY(()) bool have_multiple_function_sections =
false;
+static GTY(()) bool have_multiple_function_sections
+  = HAVE_MULTIPLE_FUNCTION_SECTIONS;
 
 /* A pointer to the base of a table that contains line
information
    for each source code line outside of .text in the
compilation unit.  */
Index: predict.c
============================================================
=======
--- predict.c	(revision 116106)
+++ predict.c	(working copy)
 -1820,6
+1820,8 
 static void
 choose_function_section (void)
 {
+  size_t len;
+
   if (DECL_SECTION_NAME (current_function_decl)
       || !targetm.have_named_sections
       /* Theoretically we can split the gnu.linkonce text
section too,
 -1836,12
+1838,19 
     return;
 
   if (cfun->function_frequency ==
FUNCTION_FREQUENCY_HOT)
-    DECL_SECTION_NAME (current_function_decl) =
-      build_string (strlen (HOT_TEXT_SECTION_NAME),
HOT_TEXT_SECTION_NAME);
+    {
+      len = strlen (HOT_TEXT_SECTION_NAME);
+      if (len)
+	DECL_SECTION_NAME (current_function_decl) =
+	  build_string (len, HOT_TEXT_SECTION_NAME);
+    }
   if (cfun->function_frequency ==
FUNCTION_FREQUENCY_UNLIKELY_EXECUTED)
-    DECL_SECTION_NAME (current_function_decl) =
-      build_string (strlen
(UNLIKELY_EXECUTED_TEXT_SECTION_NAME),
-		    UNLIKELY_EXECUTED_TEXT_SECTION_NAME);
+    {
+      len = strlen (UNLIKELY_EXECUTED_TEXT_SECTION_NAME);
+      if (len)
+	DECL_SECTION_NAME (current_function_decl) =
+	  build_string (len, UNLIKELY_EXECUTED_TEXT_SECTION_NAME);
+    }
 }
 
 static bool
Index: config/pa/som.h
============================================================
=======
--- config/pa/som.h	(revision 116106)
+++ config/pa/som.h	(working copy)
 -23,20
+23,45 
 #undef TARGET_SOM
 #define TARGET_SOM 1
 
+/* Finally, our preferred format is DWARF2_DEBUG!  */
+#define DWARF2_DEBUGGING_INFO 1
+#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
+
 /* We do not use BINCL stabs in SOM.
    ??? If it does not hurt, we probably should to avoid
useless divergence
    from other embedded stabs implementations.  */
 #undef DBX_USE_BINCL
 
-#define DBX_LINES_FUNCTION_RELATIVE 1
+/* Don't generate dbx function end.  */
+#define NO_DBX_FUNCTION_END 1
 
-/* gdb needs a null N_SO at the end of each file for
scattered loading.  */
+/* Put the eh frame data in the data section.  */  
+#define EH_FRAME_IN_DATA_SECTION 1
 
-#define DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END
+/* Provide empty names for hot and unlikely executed text
sections.  */
+#define HOT_TEXT_SECTION_NAME ""
+#define UNLIKELY_EXECUTED_TEXT_SECTION_NAME ""
 
+/* The HP linker can't handle unaligned symbol
differences.  When a
+   compilation unit has multiple function sections, the
DWARF2 output
+   code avoids emitting unaligned symbol differences. 
Effectively,
+   every function is placed in its own unnamed subspace
when using
+   SOM.  However, these subspace switches aren't noticed
by
+   dwarf2out_begin_function (), so we need to forcibly
initialize
+   have_multiple_function_sections to TRUE.  */
+#define HAVE_MULTIPLE_FUNCTION_SECTIONS true
+
+#if 0
+/* If using HP ld do not call pxdb.  Use size as a program
that does nothing
+   and returns 0.  /bin/true cannot be used because it is a
script without
+   an interpreter.  */
+#define INIT_ENVIRONMENT
"LD_PXDB=/usr/ccs/bin/size"
+#endif
+
 /* HPUX has a program 'chatr' to list the dependencies of
dynamically
    linked executables and shared libraries.  */
 #define LDD_SUFFIX "chatr"
+
 /* Look for lines like "dynamic  
/usr/lib/X11R5/libX11.sl"
    or "static    /usr/lib/X11R5/libX11.sl". 
 
 -176,6
+201,8 
 
 #define TARGET_ASM_FILE_START pa_som_file_start
 #define TARGET_ASM_INIT_SECTIONS pa_som_asm_init_sections
+#define TARGET_ASM_NAMED_SECTION  pa_som_asm_named_section
+#define TARGET_ASM_UNIQUE_SECTION pa_som_unique_section
 
 /* String to output before writable data.  */
 #define DATA_SECTION_ASM_OP "\t.SPACE
$PRIVATE$\n\t.SUBSPA $DATA$\n"
Index: config/pa/pa.c
============================================================
=======
--- config/pa/pa.c	(revision 116106)
+++ config/pa/pa.c	(working copy)
 -108,6
+108,9 
 static int pa_adjust_priority (rtx, int);
 static int pa_issue_rate (void);
 static void pa_som_asm_init_sections (void)
ATTRIBUTE_UNUSED;
+static void pa_som_asm_named_section (const char *,
unsigned int,
+				      tree) ATTRIBUTE_UNUSED;
+static void pa_som_unique_section (tree, int)
ATTRIBUTE_UNUSED;
 static section *pa_select_section (tree, int, unsigned
HOST_WIDE_INT)
      ATTRIBUTE_UNUSED;
 static void pa_encode_section_info (tree, rtx, int);
 -488,11
+491,27 
   if (flag_pic == 1 || TARGET_64BIT)
     flag_pic = 2;
 
+  if (TARGET_SOM)
+    {
+      /* We have named sections but they are only for
special purposes.  */
+      if (flag_function_sections)
+	{
+	  warning (0, "-ffunction-sections not supported for
this target");
+	  flag_function_sections = 0;
+	}
+      if (flag_data_sections)
+	{
+	  warning (0, "-fdata-sections not supported for
this target");
+	  flag_data_sections = 0;
+	}
+    }
+
   /* We can't guarantee that .dword is available for
32-bit targets.  */
   if (UNITS_PER_WORD == 4)
     targetm.asm_out.aligned_op.di = NULL;
 
-  /* The unaligned ops are only available when using GAS. 
*/
+  /* The unaligned ops are only available when using GAS. 
Note that
+     the HP linker isn't in general able to handle
unaligned fixups.  */
   if (!TARGET_GAS)
     {
       targetm.asm_out.unaligned_op.hi = NULL;
 -9372,6
+9391,40 
   exception_section = data_section;
 }
 
+/* Implement TARGET_ASM_NAMED_SECTION.  */
+
+static void
+pa_som_asm_named_section (const char *name
ATTRIBUTE_UNUSED,
+			  unsigned int flags ATTRIBUTE_UNUSED,
+                          tree decl ATTRIBUTE_UNUSED)
+{
+  /* Currently, we only use named sections for debug
sections.  */
+  if (!(flags & SECTION_DEBUG))
+    gcc_unreachable ();
+
+  if (flags & SECTION_DECLARED)
+    {
+      fprintf (asm_out_file, "\t.SPACE
$DWARF_DEBUG$\n\t.SUBSPA %s\n", name);
+      return;
+    }
+
+  fprintf (asm_out_file,
+	   "\t.SPACE
$DWARF_DEBUG$,PRIVATE,UNLOADABLE,SORT=80\n");
+  fprintf (asm_out_file,
+	   "\t.SUBSPA
%s,UNLOADABLE,ACCESS=0,ALIGN=8,SORT=8\n",
+	   name);
+}
+
+/* Implement TARGET_ASM_UNIQUE_SECTION.  */
+
+static void
+pa_som_unique_section (tree decl ATTRIBUTE_UNUSED,
+		       int reloc ATTRIBUTE_UNUSED)
+{
+  /* We don't use unique section names for declarations,
but
+     we need to override the default implementation.  */
+}
+
 /* On hpux10, the linker will give an error if we have a
reference
    in the read-only data section to a symbol defined in a
shared
    library.  Therefore, expressions that might require a
reloc can
Index: config/tc-hppa.h
============================================================
=======
RCS file: /cvs/src/src/gas/config/tc-hppa.h,v
retrieving revision 1.31
diff -u -r1.31 tc-hppa.h
--- config/tc-hppa.h	24 May 2006 11:05:42 -0000	1.31
+++ config/tc-hppa.h	13 Aug 2006 14:01:16 -0000
 -150,6
+150,7 
    the add symbol is undefined and the sub symbol is a
symbol in
    the same section as the relocation.  We also need some
way to
    specialize some code in adjust_reloc_syms.  */
+#define DIFF_EXPR_OK
 #define UNDEFINED_DIFFERENCE_OK
 #endif