Re: [PATCH] gdb.dwarf2: Define and use gdb_target_symbol_prefix for symbol prefixes

Kevin Buettner
2015-11-05T06:39:51Z

On Fri, 30 Oct 2015 11:11:33 +0000
Pedro Alves <palves@redhat.com> wrote:

> On 10/30/2015 05:25 AM, Kevin Buettner wrote:
> > On Thu, 29 Oct 2015 21:25:09 -0700
> > Kevin Buettner <kevinb@redhat.com> wrote:
> >
> >> Some of the tests in gdb.dwarf2 which use Dwarf::assemble refer to
> >> (minimal/linker) symbols created in the course of building a small
> >> test program. Some targets use a prefix such as underscore ("_") on
> >> these symbols. Many of the tests in gdb.dwarf2 do not take this into
> >> account. As a consequence, these tests fail to build, resulting
> >> either in failures or untested testcases.
> >
> > Several of the .S files in gdb.dwarf2 have the same problem. E.g.
> > when linking the test case for gdb.dwarf2/method-ptr.exp, I see a
> > linker error "undefined reference to `main'". It appears that crt0
> > is generating a reference to _main, but the .S file only provides a
> > reference to main.
> >
> > Any thoughts on what to do about this?
>
> Isn't this being addressed by gdb_target_symbol_prefix_flags in
> the existing tests that use it? E.g., gdb.arch/i386-bp_permanent.c:
>
> #ifdef SYMBOL_PREFIX
> #define SYMBOL(str) SYMBOL_PREFIX #str
> #else
> #define SYMBOL(str) #str
> #endif
>
> ...
>
> #ifdef __x86_64__
> asm(".text\n"
> " .align 8\n"
> SYMBOL (standard) ":\n"

This seems like the right general approach, but it appears to me that
the current mechanism is broken for assembly files.

For targets which need an _ prefix, gdb_target_symbol_prefix_flags
returns this:

additional_flags=-DSYMBOL_PREFIX="_"

(The code in question escapes the double quotes. I don't show that here.)

When the compiler is invoked, the relevant part of the command line
looks something like this:

rx-elf-gcc -DSYMBOL_PREFIX="_" ...

This is invoked via tcl and not via bash or similar shell. Therefore, the
value of SYMBOL_PREFIX is actually "_" (with the quotes).

(For a while, I was puzzled about why things worked in when I pasted,
into bash, the exact command from log output that showed an error. It
turns out that bash was eliminating the quotes as part of its argument
processing. When I pasted the command into tclsh instead, I was able
to reproduce the error.)

Anyway, with those quotes in place, the macro defining SYMBOL will work
just fine for inline assembler in C/C++.

But for a .S file, we need to do something like this (as shown in
gdb.arch/i386-float.S):

#define CONCAT1(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b

#ifdef SYMBOL_PREFIX
# define SYMBOL(str) CONCAT1(SYMBOL_PREFIX, str)
#else
# define SYMBOL(str) str
#endif

.text
.globl SYMBOL(main)
SYMBOL(main):

I don't understand the reason for both CONCAT1 and CONCAT2, but when
I use this code in one of the files that I'm working on, I end
up seeing an error due to the double quotes. Here's the source:

#define CONCAT1(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b

#ifdef SYMBOL_PREFIX
# define SYMBOL(str) CONCAT1(SYMBOL_PREFIX, str)
#else
# define SYMBOL(str) str
#endif

.text
SYMBOL(main): .globl SYMBOL(main)

...

And this is what it translates to:

.text
"_"main: .globl "_"main

I don't think there's any way to, within the C preprocessor, strip
the quotes from the _.

It seems to me that the way to fix this is to make
gdb_target_symbol_prefix_flags return an unquoted prefix. I.e.
it should return:

additional_flags=-DSYMBOL_PREFIX=_

instead of:

additional_flags=-DSYMBOL_PREFIX="_"

Then, within C files, SYMBOL is defined as follows:

#ifdef SYMBOL_PREFIX
#define SYMBOL(str) #SYMBOL_PREFIX #str
#else
#define SYMBOL(str) #str
#endif

Note that this is the same as before, except that I added a # to
the front of SYMBOL_PREFIX. It's possible that this won't work -
we might end up with "SYMBOL_PREFIX" instead of "_" for the prefix.
If that's the case, then some layering is needed, perhaps something
like this:

#define STRCAT1(a,b) #a #b
#ifdef SYMBOL_PREFIX
#define SYMBOL(str) STRCAT1(SYMBOL_PREFIX,str)
#else
#define SYMBOL(str) #str
#endif

I'm willing to make these changes, but I want to first be sure that
I'm not missing an easier fix.

Kevin