bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fw: How does OR Will gcc produce assembler output in intel syntax with t


From: Shawn Harrison
Subject: Fw: How does OR Will gcc produce assembler output in intel syntax with the new GAS ".intel_syntax" directive
Date: Wed, 3 Jan 2001 10:06:31 -0500

----- Original Message -----
From: "Shawn Harrison"
<address@hidden,address@hidden,address@hidden,address@hidden>
Newsgroups: comp.os.msdos.djgpp
Sent: Wednesday, January 03, 2001 9:52 AM
Subject: Re: How does OR Will gcc produce assembler output in intel syntax
with the new GAS ".intel_syntax" directive


> Hold on need, to check for BIFF > /dev/null
> (How does) if gcc already supports producing intel syntax assembler output
> and inserts the .intel_syntax directive with the -S flag how would one get
> it to do this (its obvious it doesn't)
>
> otherwise
>
> (To the maintainers of binutils) when (Will) gcc support this option?
>
> "Eli Zaretskii" <address@hidden> wrote in message
> news:address@hidden
> >
> > On Tue, 2 Jan 2001, Shawn Harrison wrote:
> >
> > > ( gcc -S ) produces AT&T syntax assembler output.
> > > How does or will gcc produce assembler output in intel syntax with the
> new
> > > GAS ".intel_syntax" directive
> >
>
> > I don't think GCC can do that.
>
> Yes of course, I know that
>
> >
> > Why do you need this?
> It makes porting code easier without a lot of unnecessary recoding, plus
if
> its something that can
> be controlled from inside the C source with the aid of #define 's then the
> code can be output to
> other assemblers that are intel syntax'ed by default
>
> > If it's to look at the produced code in syntax
> > you are used to, you can use the objdump utility on the .o file
>
> that would be great if I wanted to go from intel to at&t syntax
> say from a *.s file that was written using the .intel_syntax directive
> and compiled to an *.o file
> But its the other way around and you're just back to where you
> started at.  plus thats something gcc will not spawn by default
> to use in anything useful.
>
> > produced by a normal compilation.
>
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]