| Message ID | 4CB31A7B.7020809@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 10/11/2010 07:08 AM, Nick Clifton wrote:
> OK, revised patch attached with a simple definition of PREFIX is U_L_P is not defined.
Ok.
r~
On 11/10/2010 15:08, Nick Clifton wrote: > Hi Richard, > >>> +#define xstr(s) str(s) >>> +#define str(s) #s >>> +#define PREFIX xstr(__USER_LABEL_PREFIX__) >> >> Err, string-izing a string? > > Yeah, I know, it does not seem to make much sense, but I found that I > had to do it that way in order to get the string concatenation to work. > I did try just putting __USER_LABEL_PREFIX__ into the asm() statement, > but it just did not work. This str() and xstr() nonesense was the only > way that I found that produced the correct results. :-} I don't understand this. How did the pre-processed sources come out looking like when you just had plain ULP in the asm? If it didn't work, doesn't that mean there is a bug? Do we know if the preprocessor handles ANSI C string concatentation inside asms correctly or not? cheers, DaveK
Hi Dave, > I don't understand this. How did the pre-processed sources come out looking > like when you just had plain ULP in the asm? If it didn't work, doesn't that > mean there is a bug? Do we know if the preprocessor handles ANSI C string > concatentation inside asms correctly or not? The answer is that U_L_P is not a string, but a single character. (Despite being defined as a string by the various backends that use it). So just using U_L_P in place, like this: extern __typeof (__C_ctype_b) __C_ctype_b __asm__ (__USER_LABEL_PREFIX__ "__GI___C_ctype_b") __attribute__ ((visibility ("hidden"))); results in this error message: pr44197.c:17:22: error: expected string literal before '_' when compiled with the any toolchain that defines U_L_P to a non empty string. You can also make it happen on other targets (eg i686-pc-linux-gnu) by adding the -fleading-underscore switch to the command line. The preprocessed output looks like this: extern __typeof (__C_ctype_b) __C_ctype_b __asm__ (_ "__GI___C_ctype_b") __attribute__ ((visibility ("hidden"))); Hence the shenanigans with the string-izing macros in order to make the pr44197.c code compile. Cheers Nick
2010/10/11 Nick Clifton <nickc@redhat.com>: > Hi Dave, > >> I don't understand this. How did the pre-processed sources come out >> looking >> like when you just had plain ULP in the asm? If it didn't work, doesn't >> that >> mean there is a bug? Do we know if the preprocessor handles ANSI C string >> concatentation inside asms correctly or not? > > The answer is that U_L_P is not a string, but a single character. (Despite > being defined as a string by the various backends that use it). So just > using U_L_P in place, like this: > > extern > __typeof (__C_ctype_b) > __C_ctype_b __asm__ (__USER_LABEL_PREFIX__ "__GI___C_ctype_b") > __attribute__ ((visibility ("hidden"))); > > results in this error message: > > pr44197.c:17:22: error: expected string literal before '_' > > when compiled with the any toolchain that defines U_L_P to a non empty > string. You can also make it happen on other targets (eg i686-pc-linux-gnu) > by adding the -fleading-underscore switch to the command line. The > preprocessed output looks like this: > > extern > __typeof (__C_ctype_b) > __C_ctype_b __asm__ (_ "__GI___C_ctype_b") > __attribute__ ((visibility ("hidden"))); > > > Hence the shenanigans with the string-izing macros in order to make the > pr44197.c code compile. > > Cheers > Nick > Yes, I know this issue pretty well. I did in the past some magic here in i386.h for this. See CRT_MKSTR(__USER_LABEL_PREFIX). Sadly this magic is necessary for i386. -- Kai
2010/10/11 Dave Korn <dave.korn.cygwin@gmail.com>: > On 11/10/2010 17:56, Kai Tietz wrote: > >> Yes, I know this issue pretty well. I did in the past some magic here >> in i386.h for this. See CRT_MKSTR(__USER_LABEL_PREFIX). > > Oh, hang on: > >> #define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \ >> asm (SECTION_OP "\n\t" \ >> "call " CRT_MKSTR(__USER_LABEL_PREFIX__) #FUNC "\n" \ >> TEXT_SECTION_ASM_OP); > > Am I wrong, or is it not the case that a) you could use the proper quoted > USER_LABEL_PREFIX backend definition there, and b) that could go wrong in > cross, because it would use the build system compiler's definition of > __U_L_P__, which would be correct for the host system but not necessarily > right for the target? > > cheers, > DaveK > > There can go anything wrong, as this macro is used in libgcc (and friends only). And it never will be build native target libraries for cross compilation. Nevertheless this mixture of host/target stuff within headers is a bit irretating and somehow a kludge. Cheers, Kai
On 11/10/2010 17:37, Nick Clifton wrote: > The answer is that U_L_P is not a string, but a single character. > (Despite being defined as a string by the various backends that use it). Ah, so it's not really "stringizing a string" after all; it's quoted in the definitions of USER_LABEL_PREFIX in the backends, but the predefined __USER_LABEL_PREFIX__ macro supplied by the resulting generated compiler is unquoted. Thanks for going into the details :) cheers, DaveK
On 11/10/2010 17:56, Kai Tietz wrote: > Yes, I know this issue pretty well. I did in the past some magic here > in i386.h for this. See CRT_MKSTR(__USER_LABEL_PREFIX). Oh, hang on: > #define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \ > asm (SECTION_OP "\n\t" \ > "call " CRT_MKSTR(__USER_LABEL_PREFIX__) #FUNC "\n" \ > TEXT_SECTION_ASM_OP); Am I wrong, or is it not the case that a) you could use the proper quoted USER_LABEL_PREFIX backend definition there, and b) that could go wrong in cross, because it would use the build system compiler's definition of __U_L_P__, which would be correct for the host system but not necessarily right for the target? cheers, DaveK
On 11/10/2010 18:35, Kai Tietz wrote: > There can go anything wrong, as this macro is used in libgcc (and > friends only). Ah, indeed, so it's only ever built with the target compiler anyway. Gotcha, thanks. cheers, DaveK
Index: gcc/testsuite/gcc.c-torture/compile/pr44197.c =================================================================== --- gcc/testsuite/gcc.c-torture/compile/pr44197.c (revision 165275) +++ gcc/testsuite/gcc.c-torture/compile/pr44197.c (working copy) @@ -1,4 +1,14 @@ /* { dg-require-alias "" } */ +/* { dg-require-visibility "" } */ + +#ifndef __USER_LABEL_PREFIX__ +#define PREFIX "" +#else +#define xstr(s) str(s) +#define str(s) #s +#define PREFIX xstr(__USER_LABEL_PREFIX__) +#endif + typedef unsigned short int __uint16_t; enum { @@ -12,7 +22,7 @@ extern const __ctype_mask_t *__C_ctype_b; extern __typeof (__C_ctype_b) - __C_ctype_b __asm__ ("" "__GI___C_ctype_b") + __C_ctype_b __asm__ (PREFIX "__GI___C_ctype_b") __attribute__ ((visibility ("hidden"))); static const __ctype_mask_t __C_ctype_b_data[] = { };