On Mon, May 2, 2011 at 11:49, Andrew Pinski <pins...@gmail.com> wrote: > On Sat, Apr 30, 2011 at 2:14 PM, Chris Demetriou <c...@google.com> wrote: >> Makes -S output more easily preprocessable -- otherwise, the __i686 in >> __i686.get_pc_think.reg chokes things. > > IIRC the reason why it uses __i686 is because 586 and before does not > need to worry about the return stack addresses. > > And really I think having a name which is not able to be produced by a > C code is the best.
the "." prevents in either case, of course. And of course, either name involvinv __i686 or __x86 is reserved for implementation AFAIK. "__i686" is a preprocessor token, and when compiling with certain flags (-mcpu=i686 and perhaps others, IIRC -- I forget), it's a macro defined to 1. So, when preprocessing -S output (for whatever reason) with cpu set to i686, that beautiful: __i686.get_pc_thunk.<regname> gets turned into... 1.get_pc_thunk.<regname>. My favorite old annoyance from this was the glibc source that (at least used to) include (inline IIRC) asm code with calls to __i686.get_pc_thunk.<regname>. You couldn't compile them with -mcpu=i686 or with an i686-configured toolchain. And, there (at the time at least) IIRC the response was "not a bug." (I've not looked at that code for a long time -- dunno if it's been fixed in stock glibc.) anyway, that's one specific example where (historically) this would have been useful. i've seen others -- enough that we made this change in our compiler a few of years ago. chris
