On Fri, 19 Jan 2024, LIU Hao wrote: > ? 2024-01-18 20:54, Jan Beulich ??: > > I'm sorry, but most of your proposal may even be considered for being > > acceptable only if you would gain buy-off from the MASM guys. Anything > > MASM treats as valid ought to be permitted by gas as well (within the > > scope of certain divergence that cannot be changed in gas without > > risking to break people's code). It could probably be considered to > > introduce a "strict" mode of Intel syntax, following some / most of > > what you propose; making this the default cannot be an option. > > Thanks for your reply. > > I have attached the Markdown source for that page, modified a few hours ago. I > am planning to make some updates according to your advice tomorrow. > > And yes, I am proposing a 'strict' mode, however not for humans, only for > compilers. > > My first message references a GCC bug report, where the problematic symbol > `bx` comes from C source. I have been aware of the `/APP` and `/NO_APP`
It's #APP #NO_APP, not /APP /NO_APP, for x86_64-linux, even for -masm=intel. > markers in generated assembly, so I suspect that GAS should be able to tell > which parts are generated from a compiler and which parts are composed by > hand. Since a very long time, none but a very few gcc targets (not including i686/x64_64-linux) emit the initial #NO_APP, which have to be the very first characters of the generated assembly file, without which subsequent #APP/#NO_APP pairs are just for show. That said, I guess you're going to modify gas too. But please don't change the #APP/#NO_APP semantics for non-intel targets. brgds, H-P
