public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Clean global object source of file function name (PR target/35485)
@ 2008-10-16  8:18 David Edelsohn
  2008-10-17 15:15 ` David Edelsohn
  0 siblings, 1 reply; 4+ messages in thread
From: David Edelsohn @ 2008-10-16  8:18 UTC (permalink / raw)
  To: GCC Patches

Nothing guarantees that first_global_object_name does not contain any illegal
characters.  It needs to be cleaned like all of the other sources.

This allows libjava to link on AIX.

Bootstrapped on powerpc-ibm-aix.5.3.0.0

David


        PR target/35485
        * tree.c (get_file_function_name): Clean first_global_object_name.

Index: tree.c
===================================================================
--- tree.c      (revision 141136)
+++ tree.c      (working copy)
@@ -6882,7 +6882,10 @@

   /* If we already have a name we know to be unique, just use that.  */
   if (first_global_object_name)
-    p = first_global_object_name;
+    {
+      p = ASTRDUP (first_global_object_name);
+      clean_symbol_name (p);
+    }
   /* If the target is handling the constructors/destructors, they
      will be local to this file and the name is only necessary for
      debugging purposes.  */

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Clean global object source of file function name (PR target/35485)
  2008-10-16  8:18 [PATCH] Clean global object source of file function name (PR target/35485) David Edelsohn
@ 2008-10-17 15:15 ` David Edelsohn
  2008-10-21  7:56   ` Mark Mitchell
  0 siblings, 1 reply; 4+ messages in thread
From: David Edelsohn @ 2008-10-17 15:15 UTC (permalink / raw)
  To: GCC Patches

The original patch needed a slight tweak for type safety.

Again, nothing guarantees that a global symbol uses a characters that are
safe for a label or function on the target.  This patch cleans the
prefix produced
by the global symbol in the same way as a prefix produced by other methods.

Bootstrapped on powerpc-ibm-aix5.3.0.0

Okay for mainline?

Thanks, David


        PR target/35485
        * tree.c (get_file_function_name): Clean first_global_object_name.

Index: tree.c
===================================================================
--- tree.c      (revision 141170)
+++ tree.c      (working copy)
@@ -6923,7 +6923,10 @@

   /* If we already have a name we know to be unique, just use that.  */
   if (first_global_object_name)
-    p = first_global_object_name;
+    {
+      p = q = ASTRDUP (first_global_object_name);
+      clean_symbol_name (q);
+    }
   /* If the target is handling the constructors/destructors, they
      will be local to this file and the name is only necessary for
      debugging purposes.  */

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Clean global object source of file function name (PR  target/35485)
  2008-10-17 15:15 ` David Edelsohn
@ 2008-10-21  7:56   ` Mark Mitchell
  2008-10-21 18:42     ` David Edelsohn
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Mitchell @ 2008-10-21  7:56 UTC (permalink / raw)
  To: David Edelsohn; +Cc: GCC Patches

David Edelsohn wrote:

>         PR target/35485
>         * tree.c (get_file_function_name): Clean first_global_object_name.

This is OK, but I think it would be slightly cleaner to move the
clean_symbol_name call out of the three if/else cases and put it right
before the alloca call.  That would make obvious that we always clean
the name before allocating the final symbol.  If that makes sense to
you, that change is pre-approved.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Clean global object source of file function name (PR target/35485)
  2008-10-21  7:56   ` Mark Mitchell
@ 2008-10-21 18:42     ` David Edelsohn
  0 siblings, 0 replies; 4+ messages in thread
From: David Edelsohn @ 2008-10-21 18:42 UTC (permalink / raw)
  To: GCC Patches

On Mon, Oct 20, 2008 at 7:42 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> David Edelsohn wrote:
>
>>         PR target/35485
>>         * tree.c (get_file_function_name): Clean first_global_object_name.
>
> This is OK, but I think it would be slightly cleaner to move the
> clean_symbol_name call out of the three if/else cases and put it right
> before the alloca call.  That would make obvious that we always clean
> the name before allocating the final symbol.  If that makes sense to
> you, that change is pre-approved.

This is what I checked in:

Index: tree.c
===================================================================
--- tree.c      (revision 141258)
+++ tree.c      (working copy)
@@ -6923,7 +6923,7 @@

   /* If we already have a name we know to be unique, just use that.  */
   if (first_global_object_name)
-    p = first_global_object_name;
+    p = q = ASTRDUP (first_global_object_name);
   /* If the target is handling the constructors/destructors, they
      will be local to this file and the name is only necessary for
      debugging purposes.  */
@@ -6940,7 +6940,6 @@
       else
        p = file;
       p = q = ASTRDUP (p);
-      clean_symbol_name (q);
     }
   else
     {
@@ -6959,7 +6958,6 @@
       len = strlen (file);
       q = (char *) alloca (9 * 2 + len + 1);
       memcpy (q, file, len + 1);
-      clean_symbol_name (q);

       sprintf (q + len, "_%08X_%08X", crc32_string (0, name),
               crc32_string (0, get_random_seed (false)));
@@ -6967,6 +6965,7 @@
       p = q;
     }

+  clean_symbol_name (q);
   buf = (char *) alloca (sizeof (FILE_FUNCTION_FORMAT) + strlen (p)
                         + strlen (type));

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-10-21 17:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-16  8:18 [PATCH] Clean global object source of file function name (PR target/35485) David Edelsohn
2008-10-17 15:15 ` David Edelsohn
2008-10-21  7:56   ` Mark Mitchell
2008-10-21 18:42     ` David Edelsohn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).