RE: [RFA/commit/Win64] Remove new extra leading underscore in symbol name

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

  Why don't you simply use
bfd_get_symbol_leading_char function 
or use EXTERNAL_NAME macro defined line 65 in coffread.C
to remove the extra underscore?

Pierre Muller

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : Friday, June 18, 2010 12:26 AM
> À : gdb-patches@sourceware.org
> Cc : ktietz70@googlemail.com; Joel Brobecker
> Objet : [RFA/commit/Win64] Remove new extra leading underscore in
> symbol name
> 
> For any Ada program, the debugger no longer finds the right routine as
> the main subprogram when using the "start" command.  For instance:
> 
>     % gdb simple_main
>     (gdb) start
>     [...]
>     Temporary breakpoint 1, main (argc=1, argv=(system.address)
> 0x232470, [...]
>                             ^^^^
> 
> The expected behavior is to stop in the Ada main program:
> 
>     (gdb) start
>     [...]
>     Temporary breakpoint 1, simple_main () at simple_main.adb:4
>     4           simple.test_simple;
> 
> The problem was introduced, I believe, by a patch in bfd causing
> the names in the symbol table to now have a leading underscore:
> 
>     Adjust calling convention of x64 windows to non-leading underscore
>     http://www.sourceware.org/ml/binutils/2010-04/msg00354.html
> 
> In the case of the "start" command, the search for the name of the
> main subprogram requires GDB to find the __gnat_ada_main_program_name
> symbol.  But since the patch above got applied, GDB now sees that
> (minimal) symbol as ___gnat_ada_main_program_name (extra leading
> underscore).
> 
> Other consequences of that change of behavior:
> 
>   - Ada tasking support is broken, since it relies on other known
>     symbol names;
> 
>   - minimal symbol and symbols from debug info has non-matching names;
>     I would think that some parts of GDB's code make the assumption
>     that these names match, at least for C, but I might be
> unnecessarily
>     pessimistic.
> 
> This patch changes the COFF reader such that, for COFF/PE64, we discard
> the leading underscore.
> 
> 2010-06-17  Joel Brobecker  <brobecker@adacore.com>
> 
>         gdb/
>         * coffread.c (getsymname): Skip the leading underscore on pe64.
> 
> Tested on x64-windows with AdaCore's testsuite (we do a MinGW build).
> I'd like to commit a fix before 7.2.
> 
> Kai's input would be greatly appreciated, as he probably knows Windows
> a thousand times better than I do.
> 
> ---
>  gdb/coffread.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> diff --git a/gdb/coffread.c b/gdb/coffread.c
> index 52417b2..4ab0640 100644
> --- a/gdb/coffread.c
> +++ b/gdb/coffread.c
> @@ -1256,6 +1256,9 @@ getsymname (struct internal_syment *symbol_entry)
>  {
>    static char buffer[SYMNMLEN + 1];
>    char *result;
> +  const char *target = bfd_get_target (symfile_bfd);
> +  const int is_pe64 = (strcmp (target, "pe-x86-64") == 0
> +                       || strcmp (target, "pei-x86-64") == 0);
> 
>    if (symbol_entry->_n._n_n._n_zeroes == 0)
>      {
> @@ -1269,6 +1272,17 @@ getsymname (struct internal_syment
> *symbol_entry)
>        buffer[SYMNMLEN] = '\0';
>        result = buffer;
>      }
> +
> +  /* On x64-windows, an extra leading underscore is usually added to
> +     the symbol name.  However, the name provided in the associated
> +     debug information does not include that underscore.  So remove it
> +     now, to make the two names match.
> +
> +     This is also useful for code that searches the minimal symbols
> +     for a specific symbol whose name should be target-independent.
> */
> +  if (is_pe64 && result[0] == '_')
> +    result++;
> +
>    return result;
>  }
> 
> --
> 1.7.1