[commit/Ada] delete ada-lang.c:extract_string and use target_read_string instead

[commit/Ada] delete ada-lang.c:extract_string and use target_read_string instead

[Joel Brobecker]

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

Just a minor cleanup of ada-lang.c to remove a function that
duplicates another function implemented elsewhere.

2009-04-16  Joel Brobecker  <brobecker@adacore.com>
 
        * ada-lang.c (extract_string): Delete.
        (ada_main_name): Reimplement using target_read_string instead of
        extract_string.

This is exercised everytime we do a "start", which looks for the name
of the main routine.

Tested on x86_64-linux, no regression. Checked in.

-- 
Joel

[-- Attachment #2: string.diff --]
[-- Type: text/x-diff, Size: 1357 bytes --]

commit 04d8d0167590b9132f9a0f1e4c06476dbe892bb2
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Wed Apr 8 14:55:02 2009 -0700

        * ada-lang.c (extract_string): Delete.
        (ada_main_name): Reimplement using target_read_string instead of
        extract_string.

diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index 54f2590..814a793 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -679,8 +679,7 @@ char *
 ada_main_name (void)
 {
   struct minimal_symbol *msym;
-  CORE_ADDR main_program_name_addr;
-  static char main_program_name[1024];
+  static char *main_program_name = NULL;
 
   /* For Ada, the name of the main procedure is stored in a specific
      string constant, generated by the binder.  Look for that symbol,
@@ -691,11 +690,19 @@ ada_main_name (void)
 
   if (msym != NULL)
     {
+      CORE_ADDR main_program_name_addr;
+      int err_code;
+
       main_program_name_addr = SYMBOL_VALUE_ADDRESS (msym);
       if (main_program_name_addr == 0)
         error (_("Invalid address for Ada main program name."));
 
-      extract_string (main_program_name_addr, main_program_name);
+      xfree (main_program_name);
+      target_read_string (main_program_name_addr, &main_program_name,
+                          1024, &err_code);
+
+      if (err_code != 0)
+        return NULL;
       return main_program_name;
     }
 

Re: [commit/Ada] delete ada-lang.c:extract_string and use target_read_string instead

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> +      xfree (main_program_name);
Joel> +      target_read_string (main_program_name_addr, &main_program_name,
Joel> +                          1024, &err_code);
Joel> +
Joel> +      if (err_code != 0)
Joel> +        return NULL;
Joel>        return main_program_name;

I don't know what the Ada compiler emits here, but offhand it seems
like this needs a conversion to the host charset.

I'd imagine in most cases everything is ASCII-compatible and therefore
the problem never manifests.

Tom

Re: [commit/Ada] delete ada-lang.c:extract_string and use target_read_string instead

[Joel Brobecker]

> I don't know what the Ada compiler emits here, but offhand it seems
> like this needs a conversion to the host charset.
> I'd imagine in most cases everything is ASCII-compatible and therefore
> the problem never manifests.

Yes, it is in ascii. Can I get away without doing a conversion, or
would it be better if I did? The string just contains a symbol name.

-- 
Joel

Re: [commit/Ada] delete ada-lang.c:extract_string and use target_read_string instead

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> Yes, it is in ascii. Can I get away without doing a conversion, or
Joel> would it be better if I did? The string just contains a symbol name.

If it is always ascii then it is pretty safe as-is.  gdb assumes that
the host execution character set is ascii-compatible in several
places.  And, there is no validation or conversion of the character
set used in the debug info.  So, this isn't any worse than existing
situations :-)

Tom

Re: [commit/Ada] delete ada-lang.c:extract_string and use target_read_string instead

[Joel Brobecker]

> If it is always ascii then it is pretty safe as-is.  gdb assumes that
> the host execution character set is ascii-compatible in several
> places.  And, there is no validation or conversion of the character
> set used in the debug info.  So, this isn't any worse than existing
> situations :-)

(I have a feeling that I'm going to develop some knowledge about
charsets - actually, you guys are already to developing some charset
knowledge in me :-)

OK - if it's safe as is for now, I'm going to be lazy and leave it
as is. But thanks for the review, definitely very much appreciated.

-- 
Joel