ISO C violation (really -- style & string pasting)

ISO C violation (really -- style & string pasting)

[Donn Terry]

In i386.md, there's a potential ISO C violation:
"_GLOBAL_OFFSET_TABLE_" is spelled literally with a single
leading "_", and appears inside longer strings.  (Ditto in
i386.c.).  On many systems ((most?) ELF included), this is fine
because the namespace doesn't implictly prefix "_".

However, on those that do prefix "_" (e.g. a.out, coff for i386
Windows), this violates namespace because it collides with the user
symbol GLOBAL_OFFSET_TABLE_.

The easy fix to this is to use a #define and (ISO) string-pasting.
However, I suspect the style rules disallow string-pasting.
(If they don't, then we're done, and I'm home free.)

If I can't use string pasting, the ASn macros come close to
doing what I need, but not quite.  I'd propose introducing
a new one that does do the right thing.  Any problems with
that (other than making sure it works with old cpp-s?)

Also, there are two ways to do this: paste in (however it's
done) just the "_", or the whole symbol name.  Once I 
come up with a solution, it doesn't really matter which I do
(and I believe there already is a define for the prefix
character, but its name escapes me this moment).  Does anyone
have any preferences?

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Martin v. Loewis]

> The easy fix to this is to use a #define and (ISO) string-pasting.
> However, I suspect the style rules disallow string-pasting.

I have problems understanding how this fixes the problem (and probably
what the problem is). The symbol _GLOBAL_OFFSET_TABLE_ only appears in
assembler files, right? And it would only collide with a symbol of the
same name appearing in application source code, right? How can you
solve this conflict with the preprocessor?

Curious,
Martin

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

If the user codes the name GLOBAL_OFFSET_TABLE_ (no "_") as a global
symbol in C, and on a system that prefixes underscores to user-space
names (as in Win32/Intel and a.out, at least), the user-space name
becomes _GLOBAL_OFFSET_TABLE_ in the .s file generated
by the compiler.  _GLOBAL_OFFSET_TABLE_ is also generated by
the compiler as an internal symbol (for PIC), and the two 
collide.  GLOBAL_OFFSET_TABLE_, although an "odd" spelling, is
certainly a legal user namespace symbol.

Since the current uses of _GLOBAL_OFFSET_TABLE_ (which would
NOT present a problem for, e.g., ELF) are hardcoded into literal
strings in the compiler source (as part of instruction
source lines), which in turn becomes part of the .s file,
the symbol name needs to be changed in those strings,
which becomes a preprocessor trick.

Donn

Martin v. Loewis wrote:
> 
> > The easy fix to this is to use a #define and (ISO) string-pasting.
> > However, I suspect the style rules disallow string-pasting.
> 
> I have problems understanding how this fixes the problem (and probably
> what the problem is). The symbol _GLOBAL_OFFSET_TABLE_ only appears in
> assembler files, right? And it would only collide with a symbol of the
> same name appearing in application source code, right? How can you
> solve this conflict with the preprocessor?
> 
> Curious,
> Martin

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Martin v. Loewis]

> Since the current uses of _GLOBAL_OFFSET_TABLE_ (which would
> NOT present a problem for, e.g., ELF) are hardcoded into literal
> strings in the compiler source (as part of instruction
> source lines), which in turn becomes part of the .s file,
> the symbol name needs to be changed in those strings,
> which becomes a preprocessor trick.

I see. If this is really a problem, why not just change the compiler?
Hacking with the preprocessor seems to produce more problems than it
solves. Consider

#define SHOW(x) printf(#x " is %d\n", x);

int main()
{
  int GLOBAL_OFFSET_TABLE_ = 1,
  SHOW(GLOBAL_OFFSET_TABLE_);
}

With your hack, you'd break this program.

Regards,
Martin

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

I don't believe you're understanding my point.  I'm trying to
change gcc so it doesn't create a symbol conflict, as it currently
does.  Please see my response to Richard H and if it still isn't
clear, let's try again.

W.r.t the program below: let's change it so GLOBAL_OFFSET_TABLE_
is an extern.  (With it on the stack, it doesn't have an assembler
name, and the issue isn't relevant.)

If the objective of the program is to print a user variable by
the name of GLOBAL_OFFSET_TABLE_, then it is correct ISO C.
However, on a machine which prefixes "_" to user names, it
would in this case first modify, then print, the first entry
in the runtime support data structure whose name is currently
spelled (in assembler space) _GLOBAL_OFFSET_TABLE_.  That's
what I'm trying to fix.

Donn

Martin v. Loewis wrote:
> 
> > Since the current uses of _GLOBAL_OFFSET_TABLE_ (which would
> > NOT present a problem for, e.g., ELF) are hardcoded into literal
> > strings in the compiler source (as part of instruction
> > source lines), which in turn becomes part of the .s file,
> > the symbol name needs to be changed in those strings,
> > which becomes a preprocessor trick.
> 
> I see. If this is really a problem, why not just change the compiler?
> Hacking with the preprocessor seems to produce more problems than it
> solves. Consider
> 
> #define SHOW(x) printf(#x " is %d\n", x);
> 
> int main()
> {
>   int GLOBAL_OFFSET_TABLE_ = 1,
>   SHOW(GLOBAL_OFFSET_TABLE_);
> }
> 
> With your hack, you'd break this program.
> 
> Regards,
> Martin

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Martin v. Loewis]

> W.r.t the program below: let's change it so GLOBAL_OFFSET_TABLE_
> is an extern.  (With it on the stack, it doesn't have an assembler
> name, and the issue isn't relevant.)

I was assuming that you've proposed to introduce a new predefined
preprocessor macro into cpp with the name GLOBAL_OFFSET_TABLE_, which
would be defined to, say
__this_is_the_mangled_version_of_GLOBAL_OFFSET_TABLE_.

> I don't believe you're understanding my point.  I'm trying to
> change gcc so it doesn't create a symbol conflict, as it currently
> does.  Please see my response to Richard H and if it still isn't
> clear, let's try again.

Ok, after two iterations, I understand. I just couldn't figure out
what the specific name of the symbol has to to with 'string pasting'.

Another alternative would be to use this string concatenation only in
stage 2...

Regards,
Martin

Re: ISO C violation (really -- style & string pasting)

[Martin v. Loewis]

> W.r.t the program below: let's change it so GLOBAL_OFFSET_TABLE_
> is an extern.  (With it on the stack, it doesn't have an assembler
> name, and the issue isn't relevant.)

I was assuming that you've proposed to introduce a new predefined
preprocessor macro into cpp with the name GLOBAL_OFFSET_TABLE_, which
would be defined to, say
__this_is_the_mangled_version_of_GLOBAL_OFFSET_TABLE_.

> I don't believe you're understanding my point.  I'm trying to
> change gcc so it doesn't create a symbol conflict, as it currently
> does.  Please see my response to Richard H and if it still isn't
> clear, let's try again.

Ok, after two iterations, I understand. I just couldn't figure out
what the specific name of the symbol has to to with 'string pasting'.

Another alternative would be to use this string concatenation only in
stage 2...

Regards,
Martin

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

I don't believe you're understanding my point.  I'm trying to
change gcc so it doesn't create a symbol conflict, as it currently
does.  Please see my response to Richard H and if it still isn't
clear, let's try again.

W.r.t the program below: let's change it so GLOBAL_OFFSET_TABLE_
is an extern.  (With it on the stack, it doesn't have an assembler
name, and the issue isn't relevant.)

If the objective of the program is to print a user variable by
the name of GLOBAL_OFFSET_TABLE_, then it is correct ISO C.
However, on a machine which prefixes "_" to user names, it
would in this case first modify, then print, the first entry
in the runtime support data structure whose name is currently
spelled (in assembler space) _GLOBAL_OFFSET_TABLE_.  That's
what I'm trying to fix.

Donn

Martin v. Loewis wrote:
> 
> > Since the current uses of _GLOBAL_OFFSET_TABLE_ (which would
> > NOT present a problem for, e.g., ELF) are hardcoded into literal
> > strings in the compiler source (as part of instruction
> > source lines), which in turn becomes part of the .s file,
> > the symbol name needs to be changed in those strings,
> > which becomes a preprocessor trick.
> 
> I see. If this is really a problem, why not just change the compiler?
> Hacking with the preprocessor seems to produce more problems than it
> solves. Consider
> 
> #define SHOW(x) printf(#x " is %d\n", x);
> 
> int main()
> {
>   int GLOBAL_OFFSET_TABLE_ = 1,
>   SHOW(GLOBAL_OFFSET_TABLE_);
> }
> 
> With your hack, you'd break this program.
> 
> Regards,
> Martin

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Martin v. Loewis]

> Since the current uses of _GLOBAL_OFFSET_TABLE_ (which would
> NOT present a problem for, e.g., ELF) are hardcoded into literal
> strings in the compiler source (as part of instruction
> source lines), which in turn becomes part of the .s file,
> the symbol name needs to be changed in those strings,
> which becomes a preprocessor trick.

I see. If this is really a problem, why not just change the compiler?
Hacking with the preprocessor seems to produce more problems than it
solves. Consider

#define SHOW(x) printf(#x " is %d\n", x);

int main()
{
  int GLOBAL_OFFSET_TABLE_ = 1,
  SHOW(GLOBAL_OFFSET_TABLE_);
}

With your hack, you'd break this program.

Regards,
Martin

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

If the user codes the name GLOBAL_OFFSET_TABLE_ (no "_") as a global
symbol in C, and on a system that prefixes underscores to user-space
names (as in Win32/Intel and a.out, at least), the user-space name
becomes _GLOBAL_OFFSET_TABLE_ in the .s file generated
by the compiler.  _GLOBAL_OFFSET_TABLE_ is also generated by
the compiler as an internal symbol (for PIC), and the two 
collide.  GLOBAL_OFFSET_TABLE_, although an "odd" spelling, is
certainly a legal user namespace symbol.

Since the current uses of _GLOBAL_OFFSET_TABLE_ (which would
NOT present a problem for, e.g., ELF) are hardcoded into literal
strings in the compiler source (as part of instruction
source lines), which in turn becomes part of the .s file,
the symbol name needs to be changed in those strings,
which becomes a preprocessor trick.

Donn

Martin v. Loewis wrote:
> 
> > The easy fix to this is to use a #define and (ISO) string-pasting.
> > However, I suspect the style rules disallow string-pasting.
> 
> I have problems understanding how this fixes the problem (and probably
> what the problem is). The symbol _GLOBAL_OFFSET_TABLE_ only appears in
> assembler files, right? And it would only collide with a symbol of the
> same name appearing in application source code, right? How can you
> solve this conflict with the preprocessor?
> 
> Curious,
> Martin

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Martin v. Loewis]

> The easy fix to this is to use a #define and (ISO) string-pasting.
> However, I suspect the style rules disallow string-pasting.

I have problems understanding how this fixes the problem (and probably
what the problem is). The symbol _GLOBAL_OFFSET_TABLE_ only appears in
assembler files, right? And it would only collide with a symbol of the
same name appearing in application source code, right? How can you
solve this conflict with the preprocessor?

Curious,
Martin

Re: ISO C violation (really -- style & string pasting)

[Richard Henderson]

On Wed, Mar 24, 1999 at 05:34:18PM -0700, Donn Terry wrote:
> The easy fix to this is to use a #define and (ISO) string-pasting.
> However, I suspect the style rules disallow string-pasting.
> (If they don't, then we're done, and I'm home free.)

No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
within i386.{h,c,md} instead of the current string literal.
You can then override this for coff or whatever as needed.

Probably no one's noticed this before because coff doesn't
use pic on any currently supported platform.


r~

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

That won't work. It's exactly what I started with, but ran into
the need for string pasting.  Since "_GLOBAL_OFFSET_TABLE_" is
imbedded in longer literal strings, either I create 4 distinct strings
in the header (obscure, at best) or I use some form of string
pasting.

Here are some code excerpts:

i386.md:  output_asm_insn (\"addl $_GLOBAL_OFFSET_TABLE_+[.-%X1],%0\", operands)
;
i386.c:                                             "$_GLOBAL_OFFSET_TABLE_"),
i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_,%0", xops);
i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_+[.-%P1],%0", xops);

I'm sure you're right that no one has noticed before because
no-one (else) uses COFF and PIC.

So back to the question: what can I use to paste the strings
together that's stylistically reasonable.   I'd love to write
something like:

#define GOT_SYMBOL_NAME "__GLOBAL_OFFSET_TABLE_"
output_asm_insn ("addl $"  GOT_SYMBOL_NAME ",%0", xops);

which is perfectly legal ISO C, but I suspect that reliance
on string pasting is not going to fly.  Thus, a new ASn macro
seems at least reasonable (but I don't really like it).

Donn

Richard Henderson wrote:
> 
> On Wed, Mar 24, 1999 at 05:34:18PM -0700, Donn Terry wrote:
> > The easy fix to this is to use a #define and (ISO) string-pasting.
> > However, I suspect the style rules disallow string-pasting.
> > (If they don't, then we're done, and I'm home free.)
> 
> No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
> within i386.{h,c,md} instead of the current string literal.
> You can then override this for coff or whatever as needed.
> 
> Probably no one's noticed this before because coff doesn't
> use pic on any currently supported platform.
> 
> r~

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Richard Henderson]

On Thu, Mar 25, 1999 at 03:47:37PM -0700, Donn Terry wrote:
> i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_,%0", xops);

These references should be converted into proper arguments.
Create a SYMBOL_REF with the GLOBAL_OFFSET_TABLE_SYMBOL and
put it in xops as needed.

> i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_+[.-%P1],%0", xops);

This one should probably be converted to 

	(const:SI (plus:SI (symbol_ref:SI GLOBAL_OFFSET_TABLE_SYMBOL)
	                   (minus:SI (pc)
		                     (symbol_ref:SI FOO))))

and teach print_operand any missing bits so that 

	output_asm_insn ("addl %P1,%0", xops);

will do the right thing.



r~

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

I certainly can do that, but it's not going to be a neat
surgical strike, as the changes spread themselves across a lot
of places.  If a change of that nature is going to be 
(in principle) acceptable, then I'll do it (it may be a bit
before I do).

Donn

Richard Henderson wrote:
> 
> On Thu, Mar 25, 1999 at 03:47:37PM -0700, Donn Terry wrote:
> > i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_,%0", xops);
> 
> These references should be converted into proper arguments.
> Create a SYMBOL_REF with the GLOBAL_OFFSET_TABLE_SYMBOL and
> put it in xops as needed.
> 
> > i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_+[.-%P1],%0", xops);
> 
> This one should probably be converted to
> 
>         (const:SI (plus:SI (symbol_ref:SI GLOBAL_OFFSET_TABLE_SYMBOL)
>                            (minus:SI (pc)
>                                      (symbol_ref:SI FOO))))
> 
> and teach print_operand any missing bits so that
> 
>         output_asm_insn ("addl %P1,%0", xops);
> 
> will do the right thing.
> 
> r~

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Jeffrey A Law]

  In message < 36FAC4F0.157DA22@interix.com >you write:
  > I certainly can do that, but it's not going to be a neat
  > surgical strike, as the changes spread themselves across a lot
  > of places.  If a change of that nature is going to be 
  > (in principle) acceptable, then I'll do it (it may be a bit
  > before I do).
Yes, they are acceptable in principle.  It's actually the cleanest way to
deal with these issues.

jeff

Re: ISO C violation (really -- style & string pasting)

[Jeffrey A Law]

  In message < 36FAC4F0.157DA22@interix.com >you write:
  > I certainly can do that, but it's not going to be a neat
  > surgical strike, as the changes spread themselves across a lot
  > of places.  If a change of that nature is going to be 
  > (in principle) acceptable, then I'll do it (it may be a bit
  > before I do).
Yes, they are acceptable in principle.  It's actually the cleanest way to
deal with these issues.

jeff

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

I certainly can do that, but it's not going to be a neat
surgical strike, as the changes spread themselves across a lot
of places.  If a change of that nature is going to be 
(in principle) acceptable, then I'll do it (it may be a bit
before I do).

Donn

Richard Henderson wrote:
> 
> On Thu, Mar 25, 1999 at 03:47:37PM -0700, Donn Terry wrote:
> > i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_,%0", xops);
> 
> These references should be converted into proper arguments.
> Create a SYMBOL_REF with the GLOBAL_OFFSET_TABLE_SYMBOL and
> put it in xops as needed.
> 
> > i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_+[.-%P1],%0", xops);
> 
> This one should probably be converted to
> 
>         (const:SI (plus:SI (symbol_ref:SI GLOBAL_OFFSET_TABLE_SYMBOL)
>                            (minus:SI (pc)
>                                      (symbol_ref:SI FOO))))
> 
> and teach print_operand any missing bits so that
> 
>         output_asm_insn ("addl %P1,%0", xops);
> 
> will do the right thing.
> 
> r~

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Richard Henderson]

On Thu, Mar 25, 1999 at 03:47:37PM -0700, Donn Terry wrote:
> i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_,%0", xops);

These references should be converted into proper arguments.
Create a SYMBOL_REF with the GLOBAL_OFFSET_TABLE_SYMBOL and
put it in xops as needed.

> i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_+[.-%P1],%0", xops);

This one should probably be converted to 

	(const:SI (plus:SI (symbol_ref:SI GLOBAL_OFFSET_TABLE_SYMBOL)
	                   (minus:SI (pc)
		                     (symbol_ref:SI FOO))))

and teach print_operand any missing bits so that 

	output_asm_insn ("addl %P1,%0", xops);

will do the right thing.



r~

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

That won't work. It's exactly what I started with, but ran into
the need for string pasting.  Since "_GLOBAL_OFFSET_TABLE_" is
imbedded in longer literal strings, either I create 4 distinct strings
in the header (obscure, at best) or I use some form of string
pasting.

Here are some code excerpts:

i386.md:  output_asm_insn (\"addl $_GLOBAL_OFFSET_TABLE_+[.-%X1],%0\", operands)
;
i386.c:                                             "$_GLOBAL_OFFSET_TABLE_"),
i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_,%0", xops);
i386.c:   output_asm_insn ("addl $_GLOBAL_OFFSET_TABLE_+[.-%P1],%0", xops);

I'm sure you're right that no one has noticed before because
no-one (else) uses COFF and PIC.

So back to the question: what can I use to paste the strings
together that's stylistically reasonable.   I'd love to write
something like:

#define GOT_SYMBOL_NAME "__GLOBAL_OFFSET_TABLE_"
output_asm_insn ("addl $"  GOT_SYMBOL_NAME ",%0", xops);

which is perfectly legal ISO C, but I suspect that reliance
on string pasting is not going to fly.  Thus, a new ASn macro
seems at least reasonable (but I don't really like it).

Donn

Richard Henderson wrote:
> 
> On Wed, Mar 24, 1999 at 05:34:18PM -0700, Donn Terry wrote:
> > The easy fix to this is to use a #define and (ISO) string-pasting.
> > However, I suspect the style rules disallow string-pasting.
> > (If they don't, then we're done, and I'm home free.)
> 
> No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
> within i386.{h,c,md} instead of the current string literal.
> You can then override this for coff or whatever as needed.
> 
> Probably no one's noticed this before because coff doesn't
> use pic on any currently supported platform.
> 
> r~

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[espie]

In article < 19990325142948.E27147@cygnus.com > you write:
>No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
>within i386.{h,c,md} instead of the current string literal.
>You can then override this for coff or whatever as needed.

>Probably no one's noticed this before because coff doesn't
>use pic on any currently supported platform.

Same problem occurs with a.out, and I do happen to have an i386
a.out platform that does support pic (yep, it's a hack... an old binutils
that got hacked to get pic support for i386... we're looking to upgrading
OpenBSD to newer tools post-2.5).

Part of the problem is that you can't change gcc without changing
the linker as well... the other part of the problem is that this can
snowball: this _GLOBAL_OFFSET_TABLE_ is also present in sparc code,
and I believe this particular spelling was picked in order to be
plug-compatible with the native SunOS 4 linker...  

I'm not really sure there's a way to fix that without breaking compatibility
at one point or another... stuff that we got source to is no big deal (like 
the linker), getting people to upgrade all their tools may just be harder,
getting vendors to distribute newer dynamic libraries might be next to
impossible.

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

I agree in general, and I will definitely do the fix in a way
that won't break anyone else, but in my case, since I own the
whole tool chain, I can fix it.  (And, in fact, already have,
based on now-obsolete source bases.)

I suspect (but certainly don't know) that in the Sparc case
it doesn't trip over the prefix "_" problem, and thus isn't 
a namespace pollution issue.  A single leading _ is perfectly
reasonable if you don't prefix them to user symbols.

Donn

espie@quatramaran.ens.fr wrote:
> 
> In article < 19990325142948.E27147@cygnus.com > you write:
> >No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
> >within i386.{h,c,md} instead of the current string literal.
> >You can then override this for coff or whatever as needed.
> 
> >Probably no one's noticed this before because coff doesn't
> >use pic on any currently supported platform.
> 
> Same problem occurs with a.out, and I do happen to have an i386
> a.out platform that does support pic (yep, it's a hack... an old binutils
> that got hacked to get pic support for i386... we're looking to upgrading
> OpenBSD to newer tools post-2.5).
> 
> Part of the problem is that you can't change gcc without changing
> the linker as well... the other part of the problem is that this can
> snowball: this _GLOBAL_OFFSET_TABLE_ is also present in sparc code,
> and I believe this particular spelling was picked in order to be
> plug-compatible with the native SunOS 4 linker...
> 
> I'm not really sure there's a way to fix that without breaking compatibility
> at one point or another... stuff that we got source to is no big deal (like
> the linker), getting people to upgrade all their tools may just be harder,
> getting vendors to distribute newer dynamic libraries might be next to
> impossible.

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[Donn Terry]

I agree in general, and I will definitely do the fix in a way
that won't break anyone else, but in my case, since I own the
whole tool chain, I can fix it.  (And, in fact, already have,
based on now-obsolete source bases.)

I suspect (but certainly don't know) that in the Sparc case
it doesn't trip over the prefix "_" problem, and thus isn't 
a namespace pollution issue.  A single leading _ is perfectly
reasonable if you don't prefix them to user symbols.

Donn

espie@quatramaran.ens.fr wrote:
> 
> In article < 19990325142948.E27147@cygnus.com > you write:
> >No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
> >within i386.{h,c,md} instead of the current string literal.
> >You can then override this for coff or whatever as needed.
> 
> >Probably no one's noticed this before because coff doesn't
> >use pic on any currently supported platform.
> 
> Same problem occurs with a.out, and I do happen to have an i386
> a.out platform that does support pic (yep, it's a hack... an old binutils
> that got hacked to get pic support for i386... we're looking to upgrading
> OpenBSD to newer tools post-2.5).
> 
> Part of the problem is that you can't change gcc without changing
> the linker as well... the other part of the problem is that this can
> snowball: this _GLOBAL_OFFSET_TABLE_ is also present in sparc code,
> and I believe this particular spelling was picked in order to be
> plug-compatible with the native SunOS 4 linker...
> 
> I'm not really sure there's a way to fix that without breaking compatibility
> at one point or another... stuff that we got source to is no big deal (like
> the linker), getting people to upgrade all their tools may just be harder,
> getting vendors to distribute newer dynamic libraries might be next to
> impossible.

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================

Re: ISO C violation (really -- style & string pasting)

[espie]

In article < 19990325142948.E27147@cygnus.com > you write:
>No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
>within i386.{h,c,md} instead of the current string literal.
>You can then override this for coff or whatever as needed.

>Probably no one's noticed this before because coff doesn't
>use pic on any currently supported platform.

Same problem occurs with a.out, and I do happen to have an i386
a.out platform that does support pic (yep, it's a hack... an old binutils
that got hacked to get pic support for i386... we're looking to upgrading
OpenBSD to newer tools post-2.5).

Part of the problem is that you can't change gcc without changing
the linker as well... the other part of the problem is that this can
snowball: this _GLOBAL_OFFSET_TABLE_ is also present in sparc code,
and I believe this particular spelling was picked in order to be
plug-compatible with the native SunOS 4 linker...  

I'm not really sure there's a way to fix that without breaking compatibility
at one point or another... stuff that we got source to is no big deal (like 
the linker), getting people to upgrade all their tools may just be harder,
getting vendors to distribute newer dynamic libraries might be next to
impossible.

Re: ISO C violation (really -- style & string pasting)

[Jeffrey A Law]

  In message < 19990325142948.E27147@cygnus.com >you write:
  > On Wed, Mar 24, 1999 at 05:34:18PM -0700, Donn Terry wrote:
  > > The easy fix to this is to use a #define and (ISO) string-pasting.
  > > However, I suspect the style rules disallow string-pasting.
  > > (If they don't, then we're done, and I'm home free.)
  > 
  > No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
  > within i386.{h,c,md} instead of the current string literal.
  > You can then override this for coff or whatever as needed.
This is what I recommended too.

jeff

Re: ISO C violation (really -- style & string pasting)

[Jeffrey A Law]

  In message < 19990325142948.E27147@cygnus.com >you write:
  > On Wed, Mar 24, 1999 at 05:34:18PM -0700, Donn Terry wrote:
  > > The easy fix to this is to use a #define and (ISO) string-pasting.
  > > However, I suspect the style rules disallow string-pasting.
  > > (If they don't, then we're done, and I'm home free.)
  > 
  > No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
  > within i386.{h,c,md} instead of the current string literal.
  > You can then override this for coff or whatever as needed.
This is what I recommended too.

jeff

Re: ISO C violation (really -- style & string pasting)

[Richard Henderson]

On Wed, Mar 24, 1999 at 05:34:18PM -0700, Donn Terry wrote:
> The easy fix to this is to use a #define and (ISO) string-pasting.
> However, I suspect the style rules disallow string-pasting.
> (If they don't, then we're done, and I'm home free.)

No.  Just create a GLOBAL_OFFSET_TABLE_SYMBOL define to use
within i386.{h,c,md} instead of the current string literal.
You can then override this for coff or whatever as needed.

Probably no one's noticed this before because coff doesn't
use pic on any currently supported platform.


r~

ISO C violation (really -- style & string pasting)

[Donn Terry]

In i386.md, there's a potential ISO C violation:
"_GLOBAL_OFFSET_TABLE_" is spelled literally with a single
leading "_", and appears inside longer strings.  (Ditto in
i386.c.).  On many systems ((most?) ELF included), this is fine
because the namespace doesn't implictly prefix "_".

However, on those that do prefix "_" (e.g. a.out, coff for i386
Windows), this violates namespace because it collides with the user
symbol GLOBAL_OFFSET_TABLE_.

The easy fix to this is to use a #define and (ISO) string-pasting.
However, I suspect the style rules disallow string-pasting.
(If they don't, then we're done, and I'm home free.)

If I can't use string pasting, the ASn macros come close to
doing what I need, but not quite.  I'd propose introducing
a new one that does do the right thing.  Any problems with
that (other than making sure it works with old cpp-s?)

Also, there are two ways to do this: paste in (however it's
done) just the "_", or the whole symbol name.  Once I 
come up with a solution, it doesn't really matter which I do
(and I believe there already is a define for the prefix
character, but its name escapes me this moment).  Does anyone
have any preferences?

Donn
-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================