From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Cc: Pedro Alves <palves@redhat.com>
Subject: Re: [PATCH] gdb.dwarf2: Define and use gdb_target_symbol_prefix for symbol prefixes
Date: Thu, 05 Nov 2015 06:39:00 -0000 [thread overview]
Message-ID: <20151104233946.51336127@pinnacle.lan> (raw)
In-Reply-To: <56335065.1060100@redhat.com>
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
next prev parent reply other threads:[~2015-11-05 6:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-30 11:06 Kevin Buettner
2015-10-30 12:06 ` Kevin Buettner
2015-10-30 15:53 ` Pedro Alves
2015-11-05 6:39 ` Kevin Buettner [this message]
2015-11-05 10:46 ` Pedro Alves
2015-11-05 10:55 ` Pedro Alves
2015-11-06 5:33 ` Kevin Buettner
2015-10-30 15:51 ` Pedro Alves
2015-11-04 21:49 ` Kevin Buettner
2015-11-05 10:14 ` Pedro Alves
2015-11-05 20:01 ` Kevin Buettner
2015-11-05 21:19 ` Pedro Alves
2015-11-05 22:26 ` Kevin Buettner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151104233946.51336127@pinnacle.lan \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox