16bit x86 assembler/disassembler

16bit x86 assembler/disassembler

[James Courtier-Dutton]

Hi,

Where is a 16bit x86 assembler/disassembler

I am assuming that one is using one for grub.
Does it do C to 16bit x86 code?

Kind Regards

James

Re: 16bit x86 assembler/disassembler

[Seth Goldberg]

Hi,

   gas supports 16-bit code with .code16 directives.  What are you trying to 
do?

   --S

Quoting James Courtier-Dutton, who wrote the following on Fri, 25 Sep 2009:

> Hi,
>
> Where is a 16bit x86 assembler/disassembler
>
> I am assuming that one is using one for grub.
> Does it do C to 16bit x86 code?
>
> Kind Regards
>
> James
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: 16bit x86 assembler/disassembler

[James Courtier-Dutton]

2009/9/25 Seth Goldberg <Seth.Goldberg@sun.com>:
> Hi,
>
>  gas supports 16-bit code with .code16 directives.  What are you trying to
> do?
>

I would like to have some .c code, compile it into 16-bit x86 code. I
then want to look at the resulting 16-bit x86 code with a
disassembler.

Re: 16bit x86 assembler/disassembler

[Felix Zielcke]

Am Freitag, den 25.09.2009, 22:25 +0100 schrieb James Courtier-Dutton:
> 2009/9/25 Seth Goldberg <Seth.Goldberg@sun.com>:
> > Hi,
> >
> >  gas supports 16-bit code with .code16 directives.  What are you trying to
> > do?
> >
> 
> I would like to have some .c code, compile it into 16-bit x86 code. I
> then want to look at the resulting 16-bit x86 code with a
> disassembler.

This is totally off topic to this list.
If you want to see what asm code gcc generates just use gcc with -S
option and the asm code gets stored in an .s file

Debian has x86dis packaged, which seems to be an x86 disassembler.

But please don't continue that topic on this list.
Search another place to get help, this has absolutely nothing to do with
GRUB specific development.

-- 
Felix Zielcke
Proud Debian Maintainer

configure does not honor CC when testing for -mcmodel=large

[Seth Goldberg]

Hi,

  Setting $CC to another gcc (not in the path) fails when attempting to 
configure for 64-bit EFI if the installed gcc cannot handle -mcmodel=large. 
configure.in should be changed to honor $CC.  I'm horrible at m4 / autoconf, 
so I'm not sure what needs to be changed (otherwise, I'd provide a patch :)).

  From config.log after running ( setenv CC gcc-4.3.2; ./configure --with-platform=efi --target=x86_64):

configure:6612: result: no
configure:6617: WARNING: -mcmodel=large not supported. You won't be able to use the memory over 4GiB. Upgrade your gcc
configure:6624: checking whether option -mno-red-zone works
configure:6652: gcc -c -Os -m64 -DMCMODEL_SMALL=1 -m64 -mno-red-zone  conftest.c >&5
conftest.c:1: sorry, unimplemented: 64-bit mode not compiled in


  --S

Re: configure does not honor CC when testing for -mcmodel=large

[Seth Goldberg]

  Ok, setting TARGET_CC to gcc-4.3.2 works around this.  My assumption was that 
CC was the right environment variable (technically, it is, since I'm not 
"cross-compiling".  This going back to the core problem of all autoconf 
detecting Solaris as i386-pc-solaris and not x86_64-pc-solaris.

  --S

Quoting Seth Goldberg, who wrote the following on Fri, 25 Sep 2009:

> Hi,
>
> Setting $CC to another gcc (not in the path) fails when attempting to 
> configure for 64-bit EFI if the installed gcc cannot handle -mcmodel=large. 
> configure.in should be changed to honor $CC.  I'm horrible at m4 / autoconf, 
> so I'm not sure what needs to be changed (otherwise, I'd provide a patch :)).
>
> From config.log after running ( setenv CC gcc-4.3.2; ./configure 
> --with-platform=efi --target=x86_64):
>
> configure:6612: result: no
> configure:6617: WARNING: -mcmodel=large not supported. You won't be able to 
> use the memory over 4GiB. Upgrade your gcc
> configure:6624: checking whether option -mno-red-zone works
> configure:6652: gcc -c -Os -m64 -DMCMODEL_SMALL=1 -m64 -mno-red-zone 
> conftest.c >&5
> conftest.c:1: sorry, unimplemented: 64-bit mode not compiled in
>
>
> --S
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: configure does not honor CC when testing for -mcmodel=large

[Colin Watson]

On Fri, Sep 25, 2009 at 03:35:57PM -0700, Seth Goldberg wrote:
>  Ok, setting TARGET_CC to gcc-4.3.2 works around this.  My assumption was 
> that CC was the right environment variable (technically, it is, since I'm 
> not "cross-compiling".

Any reason not to use --host as well as --target then, so that Autoconf
knows you want to force a specific host platform? If you do that and the
values provided for host and target are the same, GRUB's configure
script won't assume cross-compilation.

> This going back to the core problem of all autoconf detecting Solaris
> as i386-pc-solaris and not x86_64-pc-solaris.

That should be fixed in config.{guess,sub}, certainly.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: configure does not honor CC when testing for -mcmodel=large

[Vladimir 'phcoder' Serbinenko]

Colin Watson wrote:
> On Fri, Sep 25, 2009 at 03:35:57PM -0700, Seth Goldberg wrote:
>   
>>  Ok, setting TARGET_CC to gcc-4.3.2 works around this.  My assumption was 
>> that CC was the right environment variable (technically, it is, since I'm 
>> not "cross-compiling".
>>     
>
> Any reason not to use --host as well as --target then, so that Autoconf
> knows you want to force a specific host platform? If you do that and the
> values provided for host and target are the same, GRUB's configure
> script won't assume cross-compilation
GRUB is one of rare projects having all 3 platform variables:
build: where gcc is executed
host: where grub-install/grub-emu/... is executed
target: the system which needs the bootloader.
Because sometimes target!=host we need 2 compilers in general case.
Additionally booting environment is different from OS so I would say
that grub2 is always cross-compiled.

Re: configure does not honor CC when testing for -mcmodel=large

[Colin Watson]

On Fri, Sep 25, 2009 at 03:29:47PM -0700, Seth Goldberg wrote:
>  Setting $CC to another gcc (not in the path) fails when attempting to  
> configure for 64-bit EFI if the installed gcc cannot handle 
> -mcmodel=large. configure.in should be changed to honor $CC.  I'm 
> horrible at m4 / autoconf, so I'm not sure what needs to be changed 
> (otherwise, I'd provide a patch :)).
>
>  From config.log after running ( setenv CC gcc-4.3.2; ./configure --with-platform=efi --target=x86_64):
>
> configure:6612: result: no
> configure:6617: WARNING: -mcmodel=large not supported. You won't be able to use the memory over 4GiB. Upgrade your gcc
> configure:6624: checking whether option -mno-red-zone works
> configure:6652: gcc -c -Os -m64 -DMCMODEL_SMALL=1 -m64 -mno-red-zone  conftest.c >&5
> conftest.c:1: sorry, unimplemented: 64-bit mode not compiled in

Don't you need to set TARGET_CC for that? If the host and target are
different, then CC is only used for the host compiler.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]