Hi,
On Tue, 3 May 2016, Sergey Korshunoff wrote:
Fixed in mob, plus some more asm bugs (32 and 64 bit).
ALT(DEF_ASM_OP1(lcall, 0xff, 3, OPC_MODRM, OPT_EA))1) or
ALT(DEF_ASM_OP1(lcall, 0xff, 3, OPC_MODRM, OPT_INDIR))2) ?
The first one. Look at the handling of OPT_INDIR, it's a no
> Fixed in mob, plus some more asm bugs (32 and 64 bit).
ALT(DEF_ASM_OP1(lcall, 0xff, 3, OPC_MODRM, OPT_EA))1) or
ALT(DEF_ASM_OP1(lcall, 0xff, 3, OPC_MODRM, OPT_INDIR))2) ?
A test code:
static unsigned long bios32_service(unsigned long service)
{
int return_code;
__asm__("lc
Hi,
On Tue, 3 May 2016, Michael Matz wrote:
Not really. It does work-around the above problem, but at the expense
of not using the one-byte opcode 0x90+reg anymore, even if possible.
Generally the opcode in i386-asm.h are sorted by some sort of preference
(e.g. first the one-byte opcodes for
Hi,
On Mon, 2 May 2016, Sergey Korshunoff wrote:
fix the "bug #39341: TCC emits wrong opcode for XCHG"
#include
int main() {
int i = 0x16789;
printf("Number: %x\n", i);
__asm__ __volatile__ ("xchg %%ah, %%al;" : "=a" (i) : "0" (i));
printf("Reversed: %x
Hi,
On Mon, 2 May 2016, Sergey Korshunoff wrote:
The mod/rm byte was simply missing from the encoding. I've corrected
this in mob.
can you post a diff? I don't see any patch in the [mob]
Meh, forgot to push. Should be in now.
Ciao,
Michael.
__
I can confirm on 32-bit. I realize you were asking for 64 bit, but I don't
have that handy.
On Mon, May 2, 2016 at 12:08 AM, Sergey Korshunoff wrote:
> bug #47379: Compare bug
> Please test/confirm on x86-64 (no bug on x86 Linux)
>
> include
> #include
> int main(int argc, char* argv[]) {
> pr
> The problem solved by a file list reordering. I think there may be a
> bug in tcc
No bug in tcc. But sections filling order differs for *.c and *.o A
problem was in user.c file calling slab allocator before its
initialization. Moving this file after slab.c in list solved a
problem.
> 'm going to check a free memory in compilation of the each file
The problem solved by a file list reordering. I think there may be a
bug in tcc which don't check a destination of the call/jump when
compiling many files in one step.
Can I disable usage of the short call/jumps? Or this is the pro
> This looks like a problem with tcc compiling a big code in one step
May be some memory must be free() when going to compile a next file
from the command line?
tcc -o aaa.exe aaa1.c aaa2.c ... aaaN.c
I'm going to check a free memory in compilation of the each file.
Hi!
It looks like tcc have some bug when compiling a big exectutable in one step.
This is a tccboot kernel. When I added some additional files to
compile (PCI bus and ethernet)
then compiled kernel hags if compiled w/o specific option
-fnocode-if-false. This option is not needed for 2 steps (compil
> > The mod/rm byte was simply missing from the encoding. I've corrected this
> > in mob.
> can you post a diff? I don't see any patch in the [mob]
Just tested the following patch for the lcall, all OK
diff --git a/i386-asm.h b/i386-asm.h
index 677519c..4e0a1c3 100644
--- a/i386-asm.h
+++ b/i386
> You realize that you can't simply copy&paste random bytes around without
> understanding the
> instruction encoding, right? You took one specific instruction with its
> specific operands and
> made that the "encoding" of all instructions with that mnemonic irrespective
> of operands.
Yes, a
12 matches
Mail list logo
