search for: html_chapter

Hi, I notice `lli -print-machineinstrs -x86-asm-syntax=(att|intel)' both prefix registers with `%'. Is this right? I thought AT&T did this and Intel didn't. The GNU gas manual concurs. http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html Cheers, Ralph.

...e: > Hi, > > I notice `lli -print-machineinstrs -x86-asm-syntax=(att|intel)' both > prefix registers with `%'. Is this right? I thought AT&T did this and > Intel didn't. The GNU gas manual concurs. > > http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html > > Cheers, > > > Ralph. > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > >

People might find this entertaining and/or useful: http://www.gnu.org/manual/autoconf-2.52/html_chapter/autoconf_10.html With the help of Jos Backus I just discovered the answer to http://lists.samba.org/pipermail/rsync-cvs/2002-January/001271.html is that Sun's test(1) is breathtakingly broken when passed a dangling symlink: $ ln -s /nowhere bad $ ls -l bad lrwxrwxrwx 1 josb user...

...do_open() and I am intending to create do_popen as an alternative to do_open() (in syscall.c). I have seen Kyle's approach of handling the forking directly, and I know I cannot handle that level of complexity. Using something like popen (I am using <http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_15.html> as reference) I can probably get away with. One of my concerns is that even though we are setting --whole-file, when I follow the program logic and the output of test runs with -vvv it is still computing CRCs and (at least seems to be) preparing deltas. Hmmm, re-reading it now...

...x mode (e.g. you can't define a function named > 'dword'), so we switched to using AT&T syntax. Ah, OK. The current gas manual says Intel register operands are undelimeted, i.e. no `%'. Perhaps they've changed. http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html#IDX585 > Intel syntax mode was retained because it's nicer to read :), and > because it may be useful in the future. As Jeff says, patches are > welcome to make it do something useful, e.g. be assemblable with MASM > or NASM. NASM might be the nicer target since it'...

Dear colleagues, Can anyone of you tell me how to write a "nabla" symbol in an R graph? Thanks in advance, Nuno ______________________________________________ Centro de Oceanografia - IO-FCUL, Portugal Center for Quantitative Fisheries Ecology - ODU, USA [[alternative HTML version deleted]]

...ReportedBy: jason at devrandom.org This is a itty bitty patch to change head to use '-n LINES' instead of '-LINES' since GNU's coreutils is deprecating that usage for POSIX 1003.1-2001 compliance. GNU's doc reference: http://www.gnu.org/software/coreutils/manual/html_chapter/coreutils_5.html#SEC18 I believe 'hean -n LINES' is portable everywhere. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

...define a function named >> 'dword'), so we switched to using AT&T syntax. > > Ah, OK. The current gas manual says Intel register operands are > undelimeted, i.e. no `%'. Perhaps they've changed. > > http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html#IDX585 Though it really doesn't matter, IIRC, this was to work around bugs in GAS. In particular (again, as I recall, could be wrong), GAS accepted registers either with or without % prefixes. If you used % prefixes, it avoided some class of bug that I don't remember any lo...

...; I notice `lli -print-machineinstrs -x86-asm-syntax=(att|intel)' both > > prefix registers with `%'. Is this right? I thought AT&T did this > > and Intel didn't. The GNU gas manual concurs. > > > > http://www.gnu.org/software/binutils/manual/gas-2.9.1/html_chapter/as_16.html > > The Intel version is just a clone of the AT&T version at this time. > No one has yet taken the time to make it produce actual Intel syntax. It's a long way towards it: # AT&T. # Intel. .text .text...

Not all the architectures can cope correctly with unaligned data, and thus the embedded init written is bogus (since it will contain random padding at the beginning, and truncated of the same amount at the end). To overcome that, make sure the rodata section with the embedded init is always aligned to 8 bytes, which should work fine for both 32bit and 64bit architectures. --- src/bin2s.pl | 1 +

Assuming you're working with an ARM target, you may also hit a problem with the alignment option on the .comm directive. Attached is a first-cut patch for this latter problem. deep On Mon, Jan 25, 2010 at 5:42 PM, Edmund Grimley Evans <Edmund.Grimley-Evans at arm.com> wrote: > I just got this error message from the GNU assembler: > > Error: alignment too large: 15 assumed

On Sat, 29 Apr 2006, Jeff Cohen wrote: > We know. Someone offered to do the Intel version, but did little more than a > huge cut and paste of the AT&T version and then lost interest. No one else > has had the time or inclination to finish the (barely begun) job. Patches > accepted :) Actually, that's not true. The LLVM X86 backend started out emitting intel mode for

I cannot follow your instructions, because asterisk segfaults on start. It never starts Can you give me instruction to trap this segfault on starting asterisk? Like gdb …..asterist –gvvvvvvc From: asterisk-users <asterisk-users-bounces at lists.digium.com> On Behalf Of Mark Murawski Sent: Saturday, August 19, 2023 11:04 PM To: asterisk-users at lists.digium.com Subject: Re:

I just got this error message from the GNU assembler: Error: alignment too large: 15 assumed Which made me laugh at first. The corresponding input line was: .align 16 Apparently what's going on here is that ".align 16" is ambiguous: on some architectures it means ".balign 16", and on some it means ".p2align 16", which would mean ".balign 65536" if

On Mon, 8 Apr 2019, @lbutlr wrote: > Really? Where outside the Received headers do IPs appear in your email headers? Well, let's see. Running a rough grep on 270-message spam folder # grep -E '^[-A-Za-z0-9]+:.*[^.0-9]{0,1}[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' ~/mail/FN | sort -u -k1,1 -t: Authentication-Results: spf=fail (sender IP is 52.233.28.167) List-Help:

We know. Someone offered to do the Intel version, but did little more than a huge cut and paste of the AT&T version and then lost interest. No one else has had the time or inclination to finish the (barely begun) job. Patches accepted :) Ralph Corderoy wrote: > Hi, > > >> It's a long way towards it: >> >> # AT&T. # Intel.

https://bugzilla.mindrot.org/show_bug.cgi?id=1980 dajoker at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dajoker at gmail.com --- Comment #6 from dajoker at gmail.com --- The ' openssh-unix-dev at mindrot.org' mailing list thread

I cleaned up the top level makefile in the tools directory. No major changes. Except I have it so that ioemmu is compiled only with x86_32. Signed-off-by: Jerone Young <jyoung5@us.ibm.com> --- tools/Makefile.orig 2005-03-17 21:03:44.000000000 -0600 +++ tools/Makefile 2005-03-22 15:05:20.000000000 -0600 @@ -1,37 +1,33 @@ +XEN_ROOT = ../ +include $(XEN_ROOT)/tools/Rules.mk -all: -