Re: Random assembler errors after update mingw64-x86_64-binutils-2.35.2-1

On 01.02.2021 10:25, Michael Soegtrop via Cygwin wrote: Hi Achim, I have some evidence that this update leads to random assembler errors. I have 3 CI failures (out of 5 runs) since the update in an open source project I maintain. The failure is always an error from the MinGW 64 assembler and

Re: Random assembler errors after update mingw64-x86_64-binutils-2.35.2-1

Michael Soegtrop via Cygwin writes: > I have some evidence that this update leads to random assembler > errors. I have 3 CI failures (out of 5 runs) since the update in an > open source project I maintain. The failure is always an error from > the MinGW 64 assembler and the error

Re: Random assembler errors after update mingw64-x86_64-binutils-2.35.2-1

An update on this: I reverted to the previous version of MinGW 64 binutils in our CI and didn't have issues since then. Best regards, Michael Am 01/02/2021 um 10:25 schrieb Michael Soegtrop: Hi Achim, I have some evidence that this update leads to random assembler errors. I have

Random assembler errors after update mingw64-x86_64-binutils-2.35.2-1

Hi Achim, I have some evidence that this update leads to random assembler errors. I have 3 CI failures (out of 5 runs) since the update in an open source project I maintain. The failure is always an error from the MinGW 64 assembler and the errors are random - that is if I rerun the same CI

Re: Request for an example x68 assembler portable Hello World script

I frequently cannot contribute discussion to Cygwin topics, but due to my work porting a database (fis-gtm) to Cygwin, I can chime in here. This is a good article to give you an overview of the different calling conventions out there: https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-

Re: Request for an example x68 assembler portable Hello World script

On 4/26/2019 5:04 PM, Jesse Thompson wrote: Ultimately what I am trying to research is how to begin building a simple compilation system of my own, so how do the *makers* of compilers deal with these differences in calling convention? They make parts of the compilers conditional on the overall

Re: Request for an example x68 assembler portable Hello World script

Just two thoughts: 1. You probably know that 'cc -S foo.c' produces foo.s which is the assembler output. Might be worthwhile examining how the experts who wrote the C compiler handle all this. The output is usually quite readable for someone prone to reading such things. 2. R

Re: Request for an example x68 assembler portable Hello World script

On Fri, 26 Apr 2019 at 15:04, Jesse Thompson <> wrote: > > > From: Eliot Moss <> > > To: cygwin@cygwin.com > > Date: Fri, 26 Apr 2019 07:16:38 -0400 > > Subject: Re: Request for an example x68 assembler portable Hello World > Ultimately what I am try

Re: Request for an example x68 assembler portable Hello World script

> From: Eliot Moss > To: cygwin@cygwin.com > Date: Fri, 26 Apr 2019 07:16:38 -0400 > Subject: Re: Request for an example x68 assembler portable Hello World script > > Der Jesse -- Someone else may be able to speak to the specifics, but > register use and calling convention

Re: Request for an example x68 assembler portable Hello World script

On 4/26/2019 3:25 AM, Jesse Thompson wrote: I would like to learn how to write assembly programs for the command line that with as little alteration as is feasable will compile both in Cygwin and in other flavors of Unix like Linux and/or FreeBSD. I am targeting only x64 CPUs and I'm perfectly h

Request for an example x68 assembler portable Hello World script

I would like to learn how to write assembly programs for the command line that with as little alteration as is feasable will compile both in Cygwin and in other flavors of Unix like Linux and/or FreeBSD. I am targeting only x64 CPUs and I'm perfectly happy to use libc calls instead of direct sysca

Re: Rebuilding gnu gcc or gnu as for the SPARC assembler

eed to build a cross tool chain (cross-assembler, cross-linker, cross-compiler, etc.) That is certainly possible with Cygwin but it's not something that is provided by default so you have to build it yourself. The gcc and binutils manuals are monolithic in that they documents all supported targets an

Rebuilding gnu gcc or gnu as for the SPARC assembler

Hello, I've installed cygwin fine on my machine. I am having trouble compiling an assembly file, which is written in the SPARC assembly architecture. When I type: as --version GNU assembler 2.17.50 20060817 Copyright 2005 Free Software Foundation, Inc. This program is free software; yo

Re: 1.5.19: assertion failure in assembler as (2.16.91 20050610)

[EMAIL PROTECTED] wrote: > .globl ___gmpn_divexact_1 > ___gmpn_divexact_1: > addl$_GLOBAL_OFFSET_TABLE_, %edx > movl[EMAIL PROTECTED](%edx), %edx Win32 does not use PLT/GOT, so this code cannot work. > This code snippet comes directly from the new GMP 4.2 (GNU Mu

1.5.19: assertion failure in assembler as (2.16.91 20050610)

There's a serious bug in the latest version (2.16.91 20050610) of the GNU assembler (as) for Cygwin. A small snippet of code triggers an assertion failure. (This code appears in the new GMP 4.2, so it prevents Cygwin from building GMP.) STEPS TO REPRODUCE: (1) Copy the six lines of 486 ass

Re: Assembler problem while trying to integrate D iompiler in GCC suite

David Friedman wrote: This is probably a better test: --- d-codegen.cc.origTue Jun 7 14:10:57 2005 +++ d-codegen.ccTue Jun 7 14:11:55 2005 @@ -1757,7 +1757,7 @@ char buf[256]; #if defined (TARGET_IS_PE_COFF) - if (DECL_ONE_ONLY (function)) + // if (DECL_ONE_ONLY (function))

RE: Assembler problem while trying to integrate D iompiler in GCC suite

4/gcc-3.4.4-1/.build/gcc/gdc -save-temps > -B/gcc/gcc-3.4.4/gcc-3.4.4-1/.build/gcc/ -B/usr/i686-pc-cygwin/bin/ > -B/usr/i686-pc-cy> > gdc: warning: -pipe ignored because -save-temps specified > socketstream.s: Assembler messages: > socketstream.s:1416: Error: Local symbol `LTHUNK0&#

Re: Assembler problem while trying to integrate D iompiler in GCC suite

David Friedman wrote: Maybe this is the problem here: ! && !defined (TARGET_IS_PE_COFF) Is TARGET_IS_PE_COFF defined for Cygwin? Yes it is: #define TARGET_IS_PE_COFF 1 Is this wrong in the d-codegen source? I'kll try what changes if I include Cygwin: ! #if defined (ASM_OUTPUT_DEF) \

Re: Assembler problem while trying to integrate D iompiler in GCC suite

Am Dienstag, 7. Juni 2005 17:25 schrieb Gerrit P. Haase: > Gerrit P. Haase wrote: [...] Sadly, neither can I help you nor am I able to provide something at least remotely useful. But I can provide something utterly useless (this mail) so you are not completely alone in this thread... Regards

Re: Assembler problem while trying to integrate D iompiler in GCC suite

Gerrit P. Haase wrote: Hi all, I'm trying to integrate the D frontend for GCC in the GCC 3.4.4 release, I'm in contact with the maintainer David Friedman, he successfully compiled the current (0.12.1) sources with MinGW and I expect that he also has tested it with other supported platforms, how

Re: Assembler problem while trying to integrate D iompiler in GCC suite

Gerrit P. Haase wrote: Maybe this is the problem here: ! && !defined (TARGET_IS_PE_COFF) Is TARGET_IS_PE_COFF defined for Cygwin? Yes it is: #define TARGET_IS_PE_COFF 1 Is this wrong in the d-codegen source? I'kll try what changes if I include Cygwin: ! #if defined (ASM_OUTPUT_DEF) \

Re: Assembler problem while trying to integrate D iompiler in GCC suite

Gerrit P. Haase wrote: Gerrit P. Haase wrote: Hi all, I'm trying to integrate the D frontend for GCC in the GCC 3.4.4 release, I'm in contact with the maintainer David Friedman, he successfully compiled the current (0.12.1) sources with MinGW and I expect that he also has tested it with other

Re: Assembler problem while trying to integrate D iompiler in GCC suite

Gerrit P. Haase wrote: Hi all, I'm trying to integrate the D frontend for GCC in the GCC 3.4.4 release, I'm in contact with the maintainer David Friedman, he successfully compiled the current (0.12.1) sources with MinGW and I expect that he also has tested it with other supported platforms, howe

Assembler problem while trying to integrate D iompiler in GCC suite

> gdc: warning: -pipe ignored because -save-temps specified socketstream.s: Assembler messages: socketstream.s:1416: Error: Local symbol `LTHUNK0' can't be equated to undefined symbol `__D3std6stream6Stream9readExactFPvkZv' socketstream.s:1416: Error: Local symbol `LTHUNK1' can'

Re: Ping: Cygwin libtool / assembler problem with -DPIC

Yes, I know I'm annoying... configure already checks for needed gcc options: checking for gcc option to produce PIC... So why don't go with it and use the option which is issued here from configure? What are all the tests good for if finally libtool overrides it with its own flags? Gerrit --

Re: Ping: Cygwin libtool / assembler problem with -DPIC

ady be using, because gmp doesn't use it and gets confused by it? Yes. Well, what I'm really asking for is to make libtool better, i.e. do s.th. about the fact that a defined PIC macro breaks assembler code e.g. to disable the macro automatically when assembler code is to be compiled

Re: Ping: Cygwin libtool / assembler problem with -DPIC

Charles Wilson wrote: That's a gmp bug, not a libtool bug. And I don't think so. IMO all assembler code cannot be compiled on Cygwin when you use -DPIC to compile it. If libtool is used as it is now, the compilation will fail, so libntool should care about this and don't use th

Re: Ping: Cygwin libtool / assembler problem with -DPIC

Hi Charles, I just don't think it is good idea to use flags for s.th. else just because they are there anywhere. If there is need for anther special flag then introduce it, exactly for this reason and this platform and for nothing else. DLL_EXPORT is the best example, if there is really a need fo

Re: Ping: Cygwin libtool / assembler problem with -DPIC

Gerrit P. Haase wrote: I think it is a bad thing to add -D flags unconditionally and for sure it is a bad thing if it is a noop. You're missing the point. *libtool* doesn't know that -DPIC means nothing for your code. On some platforms, you really have to compile DIFFERENT CODE, not just compil

Re: Ping: Cygwin libtool / assembler problem with -DPIC

27;)') > Now, on *mingw*, we do indeed (up to now) define both DLL_EXPORT and PIC > which compiling .lo's. However, for cygwin, we no longer define > DLL_EXPORT, but continue to define PIC. So the little rule above is > ineffective, and gmp ends up compiling the wrong asse

Re: libtool / assembler problem with -DPIC

Reini wrote: > Charles Wilson schrieb: >> Gerrit P. Haase wrote: >>> With GNU as PIC is not an noop, when -DPIC is used to invoke gas the >>> generated assembly is broken. I saw this problem with a >>> reautoconfiscated version of GMP. This may be unusual, but there was >>> libtool used to invok

Re: Ping: Cygwin libtool / assembler problem with -DPIC

couldn't be linked. Also I read in the GMP sources somewhere that libtool adds this flag where it is a noop on Cygwin when not compiling assembler code where it breaks things, so the conclusion was to remove the flag entirely when platform is Cygwin, I was able to build GMP and tha

Re: Ping: Cygwin libtool / assembler problem with -DPIC

e GMP sources somewhere that libtool adds this flag where it is a noop on Cygwin when not compiling assembler code where it breaks things, so the conclusion was to remove the flag entirely when platform is Cygwin, I was able to build GMP and thats it. Unfortunately I have no logs, but I tracked it down

Re: Ping: Cygwin libtool / assembler problem with -DPIC

On Tue, Oct 12, 2004 at 03:29:10PM +0200, Gerrit P. Haase wrote: > Gerrit wrote: > > PING! > > > Hello, > > > With GNU as PIC is not an noop, when -DPIC is used to invoke gas the > > generated assembly is broken. I saw this problem with a > > reautoconfiscated version of GMP. This may be unusu

Re: libtool / assembler problem with -DPIC

Charles Wilson schrieb: Gerrit P. Haase wrote: With GNU as PIC is not an noop, when -DPIC is used to invoke gas the generated assembly is broken. I saw this problem with a reautoconfiscated version of GMP. This may be unusual, but there was libtool used to invoke gas. While -DPIC is a noop for us

Re: libtool / assembler problem with -DPIC

Charles wrote: > Gerrit P. Haase wrote: >> With GNU as PIC is not an noop, when -DPIC is used to invoke gas the >> generated assembly is broken. I saw this problem with a >> reautoconfiscated version of GMP. This may be unusual, but there was >> libtool used to invoke gas. >> >> While -DPIC is

Re: libtool / assembler problem with -DPIC

Gerrit P. Haase wrote: With GNU as PIC is not an noop, when -DPIC is used to invoke gas the generated assembly is broken. I saw this problem with a reautoconfiscated version of GMP. This may be unusual, but there was libtool used to invoke gas. While -DPIC is a noop for usual compilation, it is h

Ping: Cygwin libtool / assembler problem with -DPIC

Gerrit wrote: PING! > Hello, > With GNU as PIC is not an noop, when -DPIC is used to invoke gas the > generated assembly is broken. I saw this problem with a > reautoconfiscated version of GMP. This may be unusual, but there was > libtool used to invoke gas. > While -DPIC is a noop for usual

libtool / assembler problem with -DPIC

Hello, With GNU as PIC is not an noop, when -DPIC is used to invoke gas the generated assembly is broken. I saw this problem with a reautoconfiscated version of GMP. This may be unusual, but there was libtool used to invoke gas. While -DPIC is a noop for usual compilation, it is harmful when us

Re: Assembler

Williams, Gerald S (Jerry) wrote: >> I wanted to try out my app with some deassembler, but >> I haven't found anything interesting. Which one do you >> use (in Linux)? > I don't do much X86 disassembling (most of my assembly > coding is in ARM or DSP), but I would start with ndisasm > (the nasm d

RE: Assembler

Krzysztof Duleba wrote: > I gave up. I see no chance to compile Line at all. And even > if I succeed, Line will probably bail out. Yes, I noticed that LINE was a dead project after you mentioned that you were trying to recompile it. I was hoping you would have success, since it sounded like a wor

RE: Assembler

>-Original Message- >From: Krzysztof Duleba >Sent: Thursday, February 19, 2004 4:11 PM >Subject: Re: Assembler > >Krzysztof Duleba wrote: >> >> > Googling brought me to http://line.sourceforge.net, >> > which may be more along the lines of wh

Re: Assembler

Krzysztof Duleba wrote: > > > Googling brought me to http://line.sourceforge.net, > > which may be more along the lines of what you seek. > > I tried it out, with no success. Binary version fails to run it's own hello > and rawhello programs and source produces so many serious errors during the > c

Re: Assembler

Williams, Gerald S (Jerry) wrote: Googling brought me to http://line.sourceforge.net, which may be more along the lines of what you seek. Seems to be a Dead Project(TM). No updates or releases since May 29, 2001. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports:

Re: Assembler

Brian Dessent wrote: > >> A translator that changes int 0x80 to function calls? It doesn't seem too >> difficult, but I probably miss something. > > So write a perl script. > The list of syscalls is defined in the Linux > kernel in unistd.h: >

Re: Assembler

Krzysztof Duleba wrote: > A translator that changes int 0x80 to function calls? It doesn't seem too > difficult, but I probably miss something. So write a perl script. The list of syscalls is defined in the Linux kernel in unistd.h:

Re: Assembler

Williams, Gerald S (Jerry) wrote: > Googling brought me to http://line.sourceforge.net, > which may be more along the lines of what you seek. I tried it out, with no success. Binary version fails to run it's own hello and rawhello programs and source produces so many serious errors during the com

Re: Assembler

At 09:04 AM 2/18/2004, Krzysztof Duleba you wrote: >Williams, Gerald S (Jerry) wrote: >> By asking for int 0x80 support, you're really asking >> for the ability to run precompiled Linux applications. > >What do you mean by "precompiled"? He means Linux ix86 binaries running unmodified on Windows.

Re: Assembler

Williams, Gerald S (Jerry) wrote: > int 0x80 is part of Linux, not nasm. Of course. > In fact, nasm was > generating the int 0x80 instructions just fine--they > simply don't work under Windows. So such a translator > wouldn't help. A translator that changes int 0x80 to function calls? It doesn'

Re: Assembler

printf from assembly. You should be able to make calls > to the Cygwin emulation layer the same way. The syntax is not up to me. >From your answers, I still don't know whether using int 0x80 in Cygwin is impossile (directly) or not. If Nasm (I'm limited to this assembler) can'

RE: Assembler

for a > nasm -> gcc's assembler translator? int 0x80 is part of Linux, not nasm. In fact, nasm was generating the int 0x80 instructions just fine--they simply don't work under Windows. So such a translator wouldn't help. Cygwin does a great job translating many of the system call

Re: Assembler

ked with Cygwin's gcc and works fine. As you see, I have a > good reason to believe that nasm's int 0x80 will work too. So maybe I should > simply look for a nasm -> gcc's assembler translator? > > > > On the other hand, you can get at DOS functions, > > at

Re: Assembler

inux syscalls at that level. Really? > Nor would I have expected it to. Why not? c code, translated to asm with -c -S on linux box, can be later compiled and linked with Cygwin's gcc and works fine. As you see, I have a good reason to believe that nasm's int 0x80 will work too. So

RE: Assembler

Krzysztof Duleba wrote: > What about Linux syscalls? Will Cygwin emulation layer match > it? I just Googled "int 0x80". So THAT'S what you're trying to do. :-) No, I think your experiment shows that Cygwin is not emulating Linux syscalls at that level. Nor would I have expected it to. On the ot

Re: Assembler

Williams, Gerald S (Jerry) wrote: >> I wanted to test some of my linux assembler code on my >> Windows-Cygwin box. >> Is it possible at all? > I don't know about using BIOS calls, etc., but I've > assembled and linked a few NASM assembly functions. What

RE: Assembler

Krzysztof Duleba wrote: > I wanted to test some of my linux assembler code on my > Windows-Cygwin box. > Is it possible at all? I don't know about using BIOS calls, etc., but I've assembled and linked a few NASM assembly functions. I didn't use ELF format, though. There&

Assembler

Hello I wanted to test some of my linux assembler code on my Windows-Cygwin box. Is it possible at all? Here you have a hello world: section .data t db 'Hello world',0 len equ 13 section .text global _start _start: mov edx,len mov ecx,t

gcc-3.3.1, error compiling c++ code: Assembler messages: Error: symbol `_N' is already defined

Hallo, I'm getting the following error when compiling icu-2.6.1 with gcc-3.3.1-1: $ g++ -D_REENTRANT -I. -I../common -I../common -D_REENTRANT -DHAVE_CONFIG_H -DU_I18N_IMPLEMENTATION -O4 -c -DPIC -o strmatch.o strmatch.cpp /tmp/cc3umU0v.s: Assembler messages: /tmp/cc3umU0v.s:60: Error: s

GNU Assembler and Link Errors

embly language file gets assembled using GNU's assembler on Linux/X86. So when the port to Windows stats, I think why not use GNU's assembler on the Linux Assembler file and be done with it. Well, it not working out like I thought. The process is this: 1) Using GNU's

Re: Assembler messaes:FATAL can't create /cygdrive....

On Sun, Jul 27, 2003 at 10:26:47PM -0400, Larry Hall wrote: >>You didn't -- Windows did. I'm not quite sure why /cygdrive/c/TEMP >>as the value for TEMP doesn't work for you (works for me)... See guesses >>above. > >Or . Also verify that c:\temp actually exists.

Re: Assembler messaes:FATAL can't create /cygdrive....

xactly what went wrong there. To try to work out what was wrong I wrote a simple hello_world.c program to test things. when I went to compile with gcc -I/syg/usr/include -o hello.o hello_world.c I received the following Assembler messages: Error: can't create /cygdrive/c/TEMP/ccJ6snL.o: No

Re: Assembler messaes:FATAL can't create /cygdrive....

t; should tell you exactly what went wrong there. > To try to work out what was wrong I wrote a simple hello_world.c program to > test things. when I went to compile with > gcc -I/syg/usr/include -o hello.o hello_world.c > I received the following > Assembler messages: > Error:

Assembler messaes:FATAL can't create /cygdrive....

er default output... configure:error:C compiler cannot create executables. To try to work out what was wrong I wrote a simple hello_world.c program to test things. when I went to compile with gcc -I/syg/usr/include -o hello.o hello_world.c I received the following Assembler messages: Error: ca

error with ARM cross-compiler assembler

Hi all, I got a problem with the ARM cross-compiler assembler arm-elf-as. I've built the arm-elf-as for ARM assembler but every time I tried to use the asembler to compile on an assembly file, it gives me sth like this: ... main_init.s:17: Error: Rest of line ignored. First ignored charact