[Bug gas/10775] x86 64 documentation addenda
--- Additional Comments From konrad dot schwarz at siemens dot com
2009-10-19 07:05 ---
Subject: RE: x86 64 documentation addenda
Hi,
forgive me for being so blunt, but you are wrong in rejecting some parts of the
patch.
Please see below for a detailed rebuttal. The gist of the argument is that the
additions describe things not documented in or deviations from the SDM. Some
things are documented in the AT&T documentation (which is actually the SUN
documentation). The GAS manual however, has not required reading the SUN
documentation as a prerequisite up to now; it should stay independent of AT&T
resp. SUN documentation.
The motivation for submitting this bug report is that, despite having read the
SDM, it still took several ill-spent hours of experimentation to get my code to
assemble. Had the GAS manual held the information supplied by this patch, this
would have been avoided.
Konrad Schwarz
> -Original Message-
> From: hjl dot tools at gmail dot com
> [mailto:sourceware-bugzi...@sourceware.org]
> Sent: Friday, October 16, 2009 6:30 PM
> To: Schwarz, Konrad
> Subject: [Bug gas/10775] x86 64 documentation addenda
>
>
> --- Additional Comments From hjl dot tools at gmail dot
> com 2009-10-16 16:30 ---
> (In reply to comment #0)
> > The following information is lacking from the GAS manual:
> >
> > In node (as.info)i386-Mnemonics, add at the end of 9.13.4,
> >
> > In 64-bit mode, `movabs' is the form of the mov instruction
> which loads
> > a 64-bit literal into a register.
> >
>
> movabs is not the only form to load a 64-bit literal into a register.
If there are other forms, where are they documented?
> I don't think we want to go into such details here.
movabs is not an official Intel mnemonic. Node (as.info)i386-Mnemonics
documents the detailed differences between Intel and AT&T syntax, so I don't
understand your reaction at all here.
As a practical matter, it took me maybe one or two hours to figure this out.
Other users of GAS should have it easier.
>
>
> > The AT&T/Unixware assembler is documented at
> >
> http://docs.sun.com/app/docs/doc/802-1948?l=en&q=assembler+manual and
> > http://docs.sun.com/app/docs/doc/817-5477?l=en.
What harm comes of adding this? The AT&T/Unixware assembler manual is not
available from SCO's site (makers of Unixware)---only from SUN; they also
defined the extensions to 64-bit mode. Again, establishing this probably took
an hour or two.
> >
> > In node (as.info)i386-Regs, before "* the 8 debug registers:" add
> > * The processor control register `%cr8'.
> >
> > At the end of that node, add
> >
> > The 80386 flags register is not supported as a distinct
> register. Instead, the
> > instructions `PUSH [ER]?FLAGS' and `POP [EA]?FLAGS' are
> encoded as `pushf[wlq]'
> > and `popf[wlq]'.
>
> I don't think this belongs here. People should consult SDM when
> writing assembly code.
The SDM uses the mnemonics PUSH EFLAGS and POP EFLAGS, but GAS in AT&T mode
does not support this syntax. Reference to a register %eflags results in a GAS
assembler error. Again, figuring this out took me maybe an hour. What is
being documented here are the differences between the SDM and GAS.
>
> > After node (as.info)i386-16bit, add a new section:
> >
> > 9.13.13 Writing 64-bit Code
> > ---
> > The `.code64' directive causes the assembler to emit AMD64
> ``long mode''
> > (64-bit) code. As mentioned above, the `.code32' directive
> switches to 32-bit
> > code. Which mode the assembler is in originally depends on
> the --32 and --64
> > options.
>
> I will check in this patch.
>
> diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
> index cf0bfa8..50e6e98 100644
> --- a/gas/doc/c-i386.texi
> +++ b/gas/doc/c-i386.texi
> @@ -513,6 +513,9 @@ the 4 8-bit registers: @samp{%sil},
> @samp{%dil}, @samp{%bpl}
> , @samp{%spl}.
> the 8 debug registers: @samp{%db8...@samp{%db15}.
>
> @item
> +the 8 control registers: @samp{%cr8...@samp{%cr15}.
Does GAS really support cr9--cr15? These registers are currently not
documented by the SDM.
> +
> +...@item
> the 8 SSE registers: @samp{%xmm8...@samp{%xmm15}.
> @end itemize
>
> @@ -812,8 +815,9 @@ or 64-bit x86-64 code depending on the
> default configuration
> ,
> it also supports writing code to run in real mode or in
> 16-bit protected
> mode code segments. To do this, put a @samp{.code16} or
> @samp{.code16gcc} directive before the assembly language
> instructions to
> -be run in 16-bit mode. You can switch @co...@value{as}}
> back to writing
> -normal 32-bit code with the @samp{.code32} directive.
> +be run in 16-bit mode. You can switch @co...@value{as}} to writing
> +32-bit code with the @samp{.code32} directive or 64-bit code with the
> +...@samp{.code64} directive.
Documenting how to generate 64-bit code in a section entitled "Writing 16-bit
Code" seems suboptimal.
>
> @samp{.code16gcc} provides experimental su
[Bug gas/10775] x86 64 documentation addenda
--- Additional Comments From konrad dot schwarz at siemens dot com 2009-10-19 08:52 --- Please add the other parts of the patch too. See Comment #4 for why. (Sorry for the long lines). If you wish, I can submit the proposed changes in patch form. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://sourceware.org/bugzilla/show_bug.cgi?id=10775 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10698] gold 2.20.51.0.1.20090905 fails to link linux kernel 2.6.31.1
--- Additional Comments From bero at arklinux dot org 2009-10-19 10:38 --- Not fixed. [b...@ebertswil linux-2.6.31]$ ld --version GNU gold (Linux/GNU Binutils 2.20.51.0.2.20091009) 1.9 Copyright 2008 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. [b...@ebertswil linux-2.6.31]$ make 2>&1 |tail -n 5 LD .tmp_vmlinux1 ld: error: invalid assignment to dot outside of SECTIONS ld: error: invalid assignment to dot outside of SECTIONS ld: internal error in convert_types, at ../../gold/gold.h:294 make: *** [.tmp_vmlinux1] Error 1 -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://sourceware.org/bugzilla/show_bug.cgi?id=10698 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10698] gold 2.20.51.0.1.20091009 fails to link linux kernel 2.6.31.1
-- What|Removed |Added Summary|gold 2.20.51.0.1.20090905 |gold 2.20.51.0.1.20091009 |fails to link linux kernel |fails to link linux kernel |2.6.31.1|2.6.31.1 http://sourceware.org/bugzilla/show_bug.cgi?id=10698 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10810] New: Encoding for the Thumb MOV{S} instruction
The latest ARM reference indicates that the 16-bit Thumb instruction
MOVS r1,r2
should be encoded as
LSL r1,r2,#0 // 0011
where gas encodes it as
ADDS r1,r2,#0 // 1C11
These instructions are different, since the latter clears the C (carry) and V
(overflow) flags.
gas also encodes
MOV r1,r2
as
ADDS r1,r2,#0// 1C11
whereas after ARMv6 this should be encoded as 4611. This ensures none of the
flags are set.
With Thumb2 available, gas encodes
MOVS r1,r8
as
MOV r1,r8 // 4611
whereas this should be encoded as EA5F0108. This ensures the flags are set.
--
Summary: Encoding for the Thumb MOV{S} instruction
Product: binutils
Version: 2.20
Status: NEW
Severity: normal
Priority: P2
Component: gas
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: anthony dot fox at cl dot cam dot ac dot uk
CC: bug-binutils at gnu dot org
GCC host triplet: i386-redhat-linux
GCC target triplet: arm-elf
http://sourceware.org/bugzilla/show_bug.cgi?id=10810
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10670] gold doesn't implement ld -x
-- What|Removed |Added CC||plaes at plaes dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10670 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10698] gold 2.20.51.0.1.20091009 fails to link linux kernel 2.6.31.1
--- Additional Comments From cryptooctoploid at gmail dot com 2009-10-19 15:38 --- Fixed in the 2.20 release here. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10698 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10698] gold 2.20.51.0.1.20091009 fails to link linux kernel 2.6.31.1
--- Additional Comments From ian at airs dot com 2009-10-19 15:43 --- Bernhard: you were not using the current linker sources. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10698 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10775] x86 64 documentation addenda
--- Additional Comments From hjl dot tools at gmail dot com 2009-10-19
17:08 ---
(In reply to comment #4)
> >
> > movabs is not the only form to load a 64-bit literal into a register.
>
> If there are other forms, where are they documented?
The normal "mov" insn:
mov $0x1,%rax
works fine for me.
> > I don't think we want to go into such details here.
>
> movabs is not an official Intel mnemonic. Node (as.info)i386-Mnemonics
documents the detailed differences between Intel and AT&T syntax, so I don't
understand your reaction at all here.
movabs is only required only if you want a specific insn encoding
Otherwise, you can use "mov". Also movabs can also be used in
movabs 0x1,%rax
which has a different meaning.
> >
> >
> > > The AT&T/Unixware assembler is documented at
> > >
> > http://docs.sun.com/app/docs/doc/802-1948?l=en&q=assembler+manual and
> > > http://docs.sun.com/app/docs/doc/817-5477?l=en.
>
> What harm comes of adding this? The AT&T/Unixware assembler manual is not
available from SCO's site (makers of Unixware)---only from SUN; they also
defined the extensions to 64-bit mode. Again, establishing this probably took
an hour or two.
Gas manual isn't a real x86 assembler reference. I always
point users to Sun's manual if they want to know the details.
> > >
> > > In node (as.info)i386-Regs, before "* the 8 debug registers:" add
> > > * The processor control register `%cr8'.
> > >
> > > At the end of that node, add
> > >
> > > The 80386 flags register is not supported as a distinct
> > register. Instead, the
> > > instructions `PUSH [ER]?FLAGS' and `POP [EA]?FLAGS' are
> > encoded as `pushf[wlq]'
> > > and `popf[wlq]'.
> >
> > I don't think this belongs here. People should consult SDM when
> > writing assembly code.
>
> The SDM uses the mnemonics PUSH EFLAGS and POP EFLAGS, but GAS in AT&T mode
does not support this syntax. Reference to a register %eflags results in a GAS
assembler error. Again, figuring this out took me maybe an hour. What is being
documented here are the differences between the SDM and GAS.
My Intel64/ia32 SDM doesn't have PUSH EFLAGS nor POP EFLAGS.
It only has pushf/popf.
> >
> > > After node (as.info)i386-16bit, add a new section:
> > >
> > > 9.13.13 Writing 64-bit Code
> > > ---
> > > The `.code64' directive causes the assembler to emit AMD64
> > ``long mode''
> > > (64-bit) code. As mentioned above, the `.code32' directive
> > switches to 32-bit
> > > code. Which mode the assembler is in originally depends on
> > the --32 and --64
> > > options.
> >
> > I will check in this patch.
> >
> > diff --git a/gas/doc/c-i386.texi b/gas/doc/c-i386.texi
> > index cf0bfa8..50e6e98 100644
> > --- a/gas/doc/c-i386.texi
> > +++ b/gas/doc/c-i386.texi
> > @@ -513,6 +513,9 @@ the 4 8-bit registers: @samp{%sil},
> > @samp{%dil}, @samp{%bpl}
> > , @samp{%spl}.
> > the 8 debug registers: @samp{%db8...@samp{%db15}.
> >
> > @item
> > +the 8 control registers: @samp{%cr8...@samp{%cr15}.
>
> Does GAS really support cr9--cr15? These registers are currently not
documented by the SDM.
Gas supports r0 to r15. But not all of them are valid, like
CR1, CR5, CR6, CR7, and CR9CR15. I will revert it. People
should read SDM when accessing them.
>
> Documenting how to generate 64-bit code in a section entitled "Writing 16-bit
Code" seems suboptimal.
>
Please feel free to submit a patch. Thanks.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=10775
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10802] objcopy an executable file compiled with PIE failed
-- What|Removed |Added CC||hjl dot tools at gmail dot ||com Version|unspecified |2.21 (HEAD) http://sourceware.org/bugzilla/show_bug.cgi?id=10802 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10802] objcopy an executable file compiled with PIE failed
--- Additional Comments From hjl dot tools at gmail dot com 2009-10-19 18:33 --- A patch is posted at http://sourceware.org/ml/binutils/2009-10/msg00396.html -- http://sourceware.org/bugzilla/show_bug.cgi?id=10802 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10698] gold 2.20.51.0.1.20091009 fails to link linux kernel 2.6.31.1
--- Additional Comments From bero at arklinux dot org 2009-10-19 19:15 --- Hmm, right, the kernel.org version seems to be rather out of sync with gold (odd, given it's supposed to be synced)... 2.20 doesn't compile with the options I'm using, but that's a separate issue, will open a new bug for that -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=10698 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10811] New: gold 2.20 fails to build with --enable-plugins
Trying to build gold 2.20 with --enable-plugins (actually used these days by llvm-gcc) results in ../../gold/plugin.cc: In member function 'void gold::Plugin::load()': ../../gold/plugin.cc:195: error: 'LDPT_ADD_INPUT_LIBRARY' was not declared in this scope ../../gold/plugin.cc:196: error: 'union ld_plugin_tv::' has no member named 'tv_add_input_library' -- Summary: gold 2.20 fails to build with --enable-plugins Product: binutils Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: ian at airs dot com ReportedBy: bero at arklinux dot org CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10811 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10802] objcopy an executable file compiled with PIE failed
--- Additional Comments From xake at rymdraket dot net 2009-10-19 19:36 --- (In reply to comment #1) > A patch is posted at > > http://sourceware.org/ml/binutils/2009-10/msg00396.html Works for me.:-) -- http://sourceware.org/bugzilla/show_bug.cgi?id=10802 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10802] objcopy an executable file compiled with PIE failed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-10-20 00:49 --- Subject: Bug 10802 CVSROOT:/cvs/src Module name:src Changes by: amo...@sourceware.org 2009-10-20 00:49:31 Modified files: bfd: ChangeLog opncls.c Log message: PR binutils/10802 * opncls.c (_maybe_make_executable): Make DYNAMIC files executable. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.4818&r2=1.4819 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/bfd/opncls.c.diff?cvsroot=src&r1=1.59&r2=1.60 -- http://sourceware.org/bugzilla/show_bug.cgi?id=10802 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/10802] objcopy an executable file compiled with PIE failed
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-20 00:52 --- I'll put this on the branch after verifying that testsuite results are not perturbed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=10802 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/10811] gold 2.20 fails to build with --enable-plugins
--- Additional Comments From ian at airs dot com 2009-10-20 04:10 --- Thanks for the bug report. This was an error on my part when I copied the gold sources to the binutils 2.20 release branch. This was never a problem in the main development sources, and has now been fixed on the branch in case there is a 2.20.1 release. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=10811 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
