Re: mips-elf-gcc -fno-delayed-branch problem

[Richard Sandiford]

Toshi Morita  writes:
> Maybe GAS could recognize -fno-delayed-branch to selectively disable
> branch slot filling?

I'd agree if it was -mno-delayed-branch.  I think -f* options are
generally compiler options, while -m* options are target options that
could in principle be passed down to either the assembler or the linker.

> Is there a list of optimizations performed by MIPS GAS listed somewhere?
> It would be nice if these could be selectively enabled.

The only other optimisation (if it can even be called that) is increased
accuracy regarding nop insertion.  Suppose we have something like:

.text
lw  $4,foo
addiu   $5,$5,1
jr  $31
.data
foo:
.word   1

When GAS sees the LW, it doesn't know whether the LW should use a
HI/LO pair or a GP-relative access.  It therefore creates a variant
"frag" that describes both possibilities.  As far as GAS is concerned,
the following ADDIU starts a new subblock of code.

With -Wa,-O0, GAS doesn't try to handle dependencies between these subblocks,
and just assumes the worst.  So if you assemble with -mips1, GAS has to
assume that the next subblock after the LW might use $4 straight away,
and that a nop is needed:

 <.text>:
   0:   3c04lui a0,0x0
0: R_MIPS_HI16  .data
   4:   8c84lw  a0,0(a0)
4: R_MIPS_LO16  .data
   8:   nop
   c:   24a50001addiu   a1,a1,1
  10:   03e8jr  ra
  14:   nop

At -Wa,-O1 and above it does the sensible thing:

 <.text>:
   0:   3c04lui a0,0x0
0: R_MIPS_HI16  .data
   4:   8c84lw  a0,0(a0)
4: R_MIPS_LO16  .data
   8:   24a50001addiu   a1,a1,1
   c:   03e8jr  ra
  10:   nop

TBH, I think the cases where you'd want the -O0 behaviour are
vanishingly rare.  It does in principle need less memory, and does
in principle assemble slightly quicker, but I don't think anyone would
notice unless they looked hard.

So -Wa,-O1 is better than the -Wa,-O0 that I mentioned previously.

Richard

Re: missed optimization: transforming while(n>=1) into if(n>=1)

[Siarhei Siamashka]

On Sat, May 21, 2011 at 9:07 AM, Matt Turner  wrote:
> Hi,
>
> While trying to optimize pixman, I noticed that gcc is unable to
> recognize that 'while (n >= 1)' can often be simplified to 'if (n >=
> 1)'. Consider the following example, where there are loops that
> operate on larger amounts of data and smaller loops that deal with
> small or unaligned data.
>
> int sum(const int *l, int n)
> {
>    int s = 0;
>
>    while (n >= 2) {
>        s += l[0] + l[1];
>
>        l += 2;
>        n -= 2;
>    }
>
>    while (n >= 1) {
>        s += l[0];
>
>        l += 1;
>        n -= 1;
>    }
>
>    return s;
> }
>
> Clearly the while (n >= 1) loop can never execute more than once, as n
> must be < 2, and in the body of the loop, n is decremented.
>
> The resulting machine code includes the backward branch to the top of
> the while (n >= 1) loop, which can never be taken.
>
> I suppose this is a missed optimization. Is this known, or should I
> make a new bug report?

I have an old bugreport for a somewhat related problem:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37734

It's not difficult for modify C code and replace 'while' with 'if'
where appropriate. But in the end, the compilers still can perform
pessimization even if given enough hints about how to generate
efficient code (the result of expression used for comparison with
zero, which makes it obvious that the flags already set by arithmetic
instruction can be reused without emitting an extra comparison
instruction). Though it's somewhat more complicated when targeting
MIPS processors.

-- 
Best regards,
Siarhei Siamashka

Re: missed optimization: transforming while(n>=1) into if(n>=1)

[Paolo Bonzini]

On 05/21/2011 08:07 AM, Matt Turner wrote:

I suppose this is a missed optimization. Is this known, or should I
make a new bug report?


It's always better to do that.  In this case, the bug is that when we 
compute a range from an ASSERT_EXPR, and the base variable has a known 
but symbolic range, we do not try replacing the known range of the 
symbolic operands:


n_28 = ASSERT_EXPR ;

Found new range for n_28: [-INF, 1]

...

Visiting PHI node: n_7 = PHI 

n_7: [-INF, 1]

...

Visiting PHI node: n_4 = PHI 

Found new range for n_4: [-INF, n_7]

...

And then in the body of the loop:

n_29 = ASSERT_EXPR  0>;

Found new range for n_29: [1, +INF]

This should have been the intersection of [-INF, 1] and [1, +INF], i.e. 
1.  Note that this has a chain effect: n_20 is n_29 - 1, so it will get 
a range of [0, 0].  Then, n_4 will get a range of [-INF, 1] too instead 
of the symbolic range.


Something like the attached untested patch should fix it...

Paolo
Index: tree-vrp.c
===
--- tree-vrp.c	(revision 169877)
+++ tree-vrp.c	(working copy)
@@ -718,6 +718,34 @@ vrp_bitmap_equal_p (const_bitmap b1, con
 	  && bitmap_equal_p (b1, b2)));
 }
 
+
+/* Try to replace the extreme values of the symbolic range VR with numeric
+   values from the ranges of the symbol referenced therein.  Place the
+   new range in NEW_VR, and return whether it is still symbolic.  */
+
+static bool
+resolve_symbolic_range (value_range_t *new_vr, value_range_t *vr)
+{
+  new_vr = *vr;
+  if (vr->type != VR_RANGE)
+return false;
+
+  while (!is_gimple_min_invariant (new_vr->min))
+{
+  value_range_t *min_vr = get_value_range (new_vr->min);
+  if (min_vr->type == VR_RANGE)
+new_vr->min = min_vr->min;
+}
+  while (!is_gimple_min_invariant (new_vr->max))
+{
+  value_range_t *max_vr = get_value_range (new_vr->max);
+  if (max_vr->type == VR_RANGE)
+new_vr->max = max_vr->max;
+}
+
+  return symbolic_range_p (new_vr);
+}
+
 /* Update the value range and equivalence set for variable VAR to
NEW_VR.  Return true if NEW_VR is different from VAR's previous
value.
@@ -1444,6 +1472,7 @@ extract_range_from_assert (value_range_t
 {
   tree var, cond, limit, min, max, type;
   value_range_t *var_vr, *limit_vr;
+  value_range_t var_tmp_vr, limit_tmp_vr;
   enum tree_code cond_code;
 
   var = ASSERT_EXPR_VAR (expr);
@@ -1492,10 +1521,15 @@ extract_range_from_assert (value_range_t
 
   /* LIMIT's range is only interesting if it has any useful information.  */
   if (limit_vr
-  && (limit_vr->type == VR_UNDEFINED
-	  || limit_vr->type == VR_VARYING
-	  || symbolic_range_p (limit_vr)))
+  && (limit_vr->type == VR_UNDEFINED || limit_vr->type == VR_VARYING))
 limit_vr = NULL;
+  else if (limit_vr && symbolic_range_p (limit_vr))
+{
+  if (resolve_symbolic_range (&limit_tmp_vr, limit_vr))
+limit_vr = &limit_tmp_vr;
+  else
+limit_vr = NULL;
+}
 
   /* Initially, the new range has the same set of equivalences of
  VAR's range.  This will be revised before returning the final
@@ -1737,9 +1771,15 @@ extract_range_from_assert (value_range_t
   || vr_p->type == VR_UNDEFINED
   || var_vr->type == VR_VARYING
   || var_vr->type == VR_UNDEFINED
-  || symbolic_range_p (vr_p)
-  || symbolic_range_p (var_vr))
-return;
+  || symbolic_range_p (vr_p))
+ return;
+  if (symbolic_range_p (var_vr))
+{
+  if (resolve_symbolic_range (&var_tmp_vr, var_vr))
+var_vr = &var_tmp_vr;
+  else
+return;
+}
 
   if (var_vr->type == VR_RANGE && vr_p->type == VR_RANGE)
 {

PING^2 [PATCH] Support for AMD64 targets running GNU/kFreeBSD

[Robert Millan]

Please can this patch be considered? It's several months old (sent in
Jan 2011), and it is critical to use of GCC on GNU/kFreeBSD.

2011/1/26 Robert Millan :
> Ping!
>
> 2011/1/18 Robert Millan :
>> 2011/1/14 Robert Millan :
>>> 2011/1/12 Robert Millan :
> * The headers config/kfreebsd-gnu.h etc. override
>  GLIBC_DYNAMIC_LINKER.  But the 64-bit configurations
>  x86_64-*-kfreebsd*-gnu and x86_64-*-knetbsd*-gnu do not appear to
>  use any header that would override GLIBC_DYNAMIC_LINKER32 and
>  GLIBC_DYNAMIC_LINKER64, which are what LINK_SPEC in linux64.h
>  actually uses.  Thus those configurations would use Linux-specific
>  dynamic linker settings, which seems unlikely to be as intended.

 It's not as intended. On amd64 we use /lib/ld.so.1 and
 /lib/ld-kfreebsd-x86-64.so.1.
>>>
>>> It seems x86_64-kfreebsd-gnu has been broken for a while.  I
>>> just realized that I wrote a patch to fix this in 2006 [1], but
>>> somehow it was never merged in GCC (actually I'm not even
>>> sure I submitted it).
>>>
>>> In the meantime Debian GNU/kFreeBSD has been using this
>>> patch to build GCC on their "kfreebsd-amd64" port.
>>>
>>> I can prepare an updated version of this patch (relative to
>>> trunk + your linux.h overhaul [2]).
>>
>> Here is it.
>>
>> --
>> Robert Millan
>>
>
>
>
> --
> Robert Millan
>



-- 
Robert Millan
2011-01-18  Robert Millan  

Support for AMD64 targets running GNU/kFreeBSD.

* config.gcc (tm_file): Include `i386/kfreebsd-gnu.h' on
x86_64-*-kfreebsd*-gnu.
* config/i386/kfreebsd-gnu.h
(GLIBC_DYNAMIC_LINKER32): If defined, redefine to "/lib/ld.so.1".
(GLIBC_DYNAMIC_LINKER64): If defined, redefine to
"/lib/ld-kfreebsd-x86-64.so.1".

* config/i386/linux.h (LINK_EMULATION): Redefine this macro
to a noop filter, which can be overriden by other headers.
* config/i386/linux64.h (LINK_SPEC): Process emulation names
through LINK_EMULATION().
* config/kfreebsd-gnu.h (LINK_EMULATION): Redefine to append
a "_fbsd" suffix.
* config/i386/kfreebsd-gnu.h (LINK_EMULATION): Remove macro
(superceded by the definition in config/kfreebsd-gnu.h).

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 168952)
+++ gcc/config.gcc  (working copy)
@@ -1267,7 +1267,7 @@
case ${target} in
x86_64-*-linux*)
  default_gnu_indirect_function=glibc-2011 ;;
-   x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h" ;;
+   x86_64-*-kfreebsd*-gnu) tm_file="${tm_file} kfreebsd-gnu.h 
i386/kfreebsd-gnu.h" ;;
x86_64-*-knetbsd*-gnu) tm_file="${tm_file} knetbsd-gnu.h" ;;
esac
tmake_file="${tmake_file} i386/t-linux64 i386/t-crtstuff i386/t-crtpc 
i386/t-crtfm t-dfprules"
Index: gcc/config/i386/linux.h
===
--- gcc/config/i386/linux.h (revision 168952)
+++ gcc/config/i386/linux.h (working copy)
@@ -91,7 +91,7 @@
done.  */
 
 /* These macros may be overridden in k*bsd-gnu.h and i386/k*bsd-gnu.h. */
-#define LINK_EMULATION "elf_i386"
+#define LINK_EMULATION(em) em
 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
 
 #undef  ASM_SPEC
@@ -100,7 +100,7 @@
 
 #undef  SUBTARGET_EXTRA_SPECS
 #define SUBTARGET_EXTRA_SPECS \
-  { "link_emulation", LINK_EMULATION },\
+  { "link_emulation", LINK_EMULATION("elf_i386") },\
   { "dynamic_linker", LINUX_DYNAMIC_LINKER }
 
 #undef LINK_SPEC
Index: gcc/config/i386/kfreebsd-gnu.h
===
--- gcc/config/i386/kfreebsd-gnu.h  (revision 168952)
+++ gcc/config/i386/kfreebsd-gnu.h  (working copy)
@@ -19,7 +19,15 @@
 along with GCC; see the file COPYING3.  If not see
 .  */
 
-#undef LINK_EMULATION
-#define LINK_EMULATION "elf_i386_fbsd"
+#ifdef GLIBC_DYNAMIC_LINKER32
+#undef GLIBC_DYNAMIC_LINKER32
+#define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
+#endif
+
+#ifdef GLIBC_DYNAMIC_LINKER64
+#undef GLIBC_DYNAMIC_LINKER64
+#define GLIBC_DYNAMIC_LINKER64 "/lib/ld-kfreebsd-x86-64.so.1"
+#endif
+
 #undef REG_NAME
 #define REG_NAME(reg) sc_ ## reg
Index: gcc/config/i386/linux64.h
===
--- gcc/config/i386/linux64.h   (revision 168952)
+++ gcc/config/i386/linux64.h   (working copy)
@@ -75,7 +75,8 @@
  %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}"
 
 #undef LINK_SPEC
-#define LINK_SPEC "%{" SPEC_64 ":-m elf_x86_64} %{" SPEC_32 ":-m elf_i386} \
+#define LINK_SPEC "%{" SPEC_64 ":-m " LINK_EMULATION("elf_x86_64") "} \
+  %{" SPEC_32 ":-m " LINK_EMULATION("elf_i386") "} \
   %{shared:-shared} \
   %{!shared: \
 %{!static: \
Index: gcc/config/kfreebsd-gnu.h
===
--- gcc/config/kfreebsd-gnu.h   (revision 168952)
+++ gcc

X32 project status update

[H.J. Lu]

Hi,

This is the x32 project status update:

https://sites.google.com/site/x32abi/

With the latest x32 kernel semctl bug fix, C, C++ and Fortran
test results on GCC x32 branch only show one serious bug:

FAIL: gcc.c-torture/execute/builtins/strcspn.c execution,  -O1

It is due to the combine issue:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49088

I am planning to prepare merging GCC x32 branch with trunk
followed by glibc and gdb patches.

The current x32 implementation uses DImode for Pmode.
I chose it because:

1. x32 process is running in 64bit mode. Hardware pointer
in x32 is 64bit.
2. x86 backend maps Pmode to hardware pointer mode.
Use SImode for Pmode requires extra changes in x86 bakend.
3. 32bit base/index are supported in x32 when they are
generated by middle-end via ptr_mode which is 32bit.

But I'd like to keep the option open to switch Pmode to
SImode later if it can provide better performance and/or
reduce the code size.

GCC x32 branch is available at:

svn://gcc.gnu.org/svn/gcc/branches/x32

Majority of changes are in x86 backend and there are also
some middle-end changes. I appreciate any feedbacks.

Thanks.

-- 
H.J.

Re: X32 project status update

[Arnd Bergmann]

On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
> This is the x32 project status update:
> 
> https://sites.google.com/site/x32abi/
> 

I've had another look at the kernel patch. It basically
looks all good, but the system call table appears to
diverge from the x86_64 list for no (documented) reason,
in the calls above 302. Is that intentional?

I can see why you might want to keep the numbers identical,
but if they are already different, why not use the generic
system call table from asm-generic/unistd.h for the new
ABI?

Arnd

Re: X32 project status update

[H.J. Lu]

On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann  wrote:
> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>> This is the x32 project status update:
>>
>> https://sites.google.com/site/x32abi/
>>
>
> I've had another look at the kernel patch. It basically
> looks all good, but the system call table appears to
> diverge from the x86_64 list for no (documented) reason,
> in the calls above 302. Is that intentional?
>
> I can see why you might want to keep the numbers identical,
> but if they are already different, why not use the generic
> system call table from asm-generic/unistd.h for the new
> ABI?

We can sort it out when we start merging x32 kernel changes.


-- 
H.J.

Re: X32 project status update

[H.J. Lu]

On Sat, May 21, 2011 at 8:34 AM, H.J. Lu  wrote:
> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann  wrote:
>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>> This is the x32 project status update:
>>>
>>> https://sites.google.com/site/x32abi/
>>>
>>
>> I've had another look at the kernel patch. It basically
>> looks all good, but the system call table appears to
>> diverge from the x86_64 list for no (documented) reason,
>> in the calls above 302. Is that intentional?
>>
>> I can see why you might want to keep the numbers identical,
>> but if they are already different, why not use the generic
>> system call table from asm-generic/unistd.h for the new
>> ABI?
>
> We can sort it out when we start merging x32 kernel changes.
>

Peter, is that possible to use the single syscall table for
both x86-64 and x32 system calls? Out of 300+ system
calls, only 84 are different for x86-64 and x32.  That
is additional 8*84 == 672 bytes in syscall table.


-- 
H.J.

Re: X32 project status update

[H. Peter Anvin]

On 05/21/2011 09:27 AM, H.J. Lu wrote:
> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu  wrote:
>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann  wrote:
>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
 This is the x32 project status update:

 https://sites.google.com/site/x32abi/

>>>
>>> I've had another look at the kernel patch. It basically
>>> looks all good, but the system call table appears to
>>> diverge from the x86_64 list for no (documented) reason,
>>> in the calls above 302. Is that intentional?
>>>
>>> I can see why you might want to keep the numbers identical,
>>> but if they are already different, why not use the generic
>>> system call table from asm-generic/unistd.h for the new
>>> ABI?
>>
>> We can sort it out when we start merging x32 kernel changes.
>>
> 
> Peter, is that possible to use the single syscall table for
> both x86-64 and x32 system calls? Out of 300+ system
> calls, only 84 are different for x86-64 and x32.  That
> is additional 8*84 == 672 bytes in syscall table.
> 

Sort of... remember we talked about merging system calls at the tail
end?  The problem with that is that some system calls (like read()!)
actually are different system calls in very subtle situations, due to
abuse in some subsystems of the is_compat() construct.  I think that may
mean we have to have an unambiguous flag after all...

Now, perhaps we can use a high bit for that and mask it before dispatch,
then we don't need the additional table.  A bit of a hack, but it should
work.

-hpa

RE: X32 project status update

[Anvin, H Peter]

I'll look at it but possibly not until the weekend.

-Original Message-
From: H.J. Lu [hjl.to...@gmail.com]
Sent: Saturday, May 21, 2011 12:39 PM Pacific Standard Time
To: Anvin, H Peter
Cc: x32-...@googlegroups.com; Arnd Bergmann; GCC Development; GNU C Library; 
LKML
Subject: Re: X32 project status update


On Sat, May 21, 2011 at 11:55 AM, H. Peter Anvin
 wrote:
> On 05/21/2011 09:27 AM, H.J. Lu wrote:
>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu  wrote:
>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann  wrote:
 On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
> This is the x32 project status update:
>
> https://sites.google.com/site/x32abi/
>

 I've had another look at the kernel patch. It basically
 looks all good, but the system call table appears to
 diverge from the x86_64 list for no (documented) reason,
 in the calls above 302. Is that intentional?

 I can see why you might want to keep the numbers identical,
 but if they are already different, why not use the generic
 system call table from asm-generic/unistd.h for the new
 ABI?
>>>
>>> We can sort it out when we start merging x32 kernel changes.
>>>
>>
>> Peter, is that possible to use the single syscall table for
>> both x86-64 and x32 system calls? Out of 300+ system
>> calls, only 84 are different for x86-64 and x32.  That
>> is additional 8*84 == 672 bytes in syscall table.
>>
>
> Sort of... remember we talked about merging system calls at the tail
> end?  The problem with that is that some system calls (like read()!)
> actually are different system calls in very subtle situations, due to
> abuse in some subsystems of the is_compat() construct.  I think that may
> mean we have to have an unambiguous flag after all...
>
> Now, perhaps we can use a high bit for that and mask it before dispatch,
> then we don't need the additional table.  A bit of a hack, but it should
> work.

How about this patch?

   Merge x32 system calls with x86-64 system calls

Implemented with

1. Mark all x86-64 specific system calls with __NR_64_.
2. Mark all x32 specific system calls with __NR_x32_.
3. Include unistd_64_compat.h, instead of unistd_x32.h for kernel
build, which provides __NR_ versions of x86-64 specific system calls.
4. Append x32 specific system calls after the current x86-64 system
calls.
5. Generate unistd_x32.h from unistd_64.h, replacing __NR_x32_ with
_NR_.
6. Install user-space unistd_64.h, replacing __NR_64_ with _NR_.

--
H.J.

gcc-4.7-20110521 is now available

[gccadmin]

Snapshot gcc-4.7-20110521 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110521/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 174012

You'll find:

 gcc-4.7-20110521.tar.bz2 Complete GCC (includes all of below)

  MD5=a78e0630ab45c4a7989a0af0cf7ec84f
  SHA1=1d3285c86df7d401e9354df741856e141bced239

 gcc-core-4.7-20110521.tar.bz2C front end and core compiler

  MD5=1994353623fd8f0fe7c8c949befbe945
  SHA1=cf8e5541da2f535e5d5c3ce332a851a9ba4810e2

 gcc-ada-4.7-20110521.tar.bz2 Ada front end and runtime

  MD5=e183134b4db23c675afc84afaa6b5c70
  SHA1=8604187bfca221fa29a7ed2592922e8ef347724f

 gcc-fortran-4.7-20110521.tar.bz2 Fortran front end and runtime

  MD5=ad494f219bb3f0ecda6965bebff6
  SHA1=47830cd4053ca6c77cb5b9f5a01b16a036433738

 gcc-g++-4.7-20110521.tar.bz2 C++ front end and runtime

  MD5=5a65a931fa421482e2d5d4be0af8afa1
  SHA1=2f7c26dd3df61060d224808afed5d9817b21e5c1

 gcc-go-4.7-20110521.tar.bz2  Go front end and runtime

  MD5=348e6f5b1f499adee910a069aa4b76da
  SHA1=4df38bc14caca0431033a5aa109872b992c4672c

 gcc-java-4.7-20110521.tar.bz2Java front end and runtime

  MD5=17643b3bba228c09dbffa4ae416a8042
  SHA1=097c2097c434de2de80701e6c441255070ea12c1

 gcc-objc-4.7-20110521.tar.bz2Objective-C front end and runtime

  MD5=3749a31233fab6258718cd30c66bbd3c
  SHA1=2c061a8a5ecee0588852b0b1c93650d6b88328e9

 gcc-testsuite-4.7-20110521.tar.bz2   The GCC testsuite

  MD5=b21894390ff85f11db2d42a74dae46f0
  SHA1=ae82f1badb552eb14e184d78fef96b512f417a8e

Diffs from 4.7-20110514 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: X32 project status update

[H.J. Lu]

On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter  wrote:
> I'll look at it but possibly not until the weekend.

I checked it into hjl/x32/syscall branch at

http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.38.y.git;a=summary


H.J.
---
> -Original Message-
> From: H.J. Lu [hjl.to...@gmail.com]
> Sent: Saturday, May 21, 2011 12:39 PM Pacific Standard Time
> To: Anvin, H Peter
> Cc: x32-...@googlegroups.com; Arnd Bergmann; GCC Development; GNU C Library;
> LKML
> Subject: Re: X32 project status update
>
> On Sat, May 21, 2011 at 11:55 AM, H. Peter Anvin
>  wrote:
>> On 05/21/2011 09:27 AM, H.J. Lu wrote:
>>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu  wrote:
 On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann  wrote:
> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>> This is the x32 project status update:
>>
>> https://sites.google.com/site/x32abi/
>>
>
> I've had another look at the kernel patch. It basically
> looks all good, but the system call table appears to
> diverge from the x86_64 list for no (documented) reason,
> in the calls above 302. Is that intentional?
>
> I can see why you might want to keep the numbers identical,
> but if they are already different, why not use the generic
> system call table from asm-generic/unistd.h for the new
> ABI?

 We can sort it out when we start merging x32 kernel changes.

>>>
>>> Peter, is that possible to use the single syscall table for
>>> both x86-64 and x32 system calls? Out of 300+ system
>>> calls, only 84 are different for x86-64 and x32.  That
>>> is additional 8*84 == 672 bytes in syscall table.
>>>
>>
>> Sort of... remember we talked about merging system calls at the tail
>> end?  The problem with that is that some system calls (like read()!)
>> actually are different system calls in very subtle situations, due to
>> abuse in some subsystems of the is_compat() construct.  I think that may
>> mean we have to have an unambiguous flag after all...
>>
>> Now, perhaps we can use a high bit for that and mask it before dispatch,
>> then we don't need the additional table.  A bit of a hack, but it should
>> work.
>
> How about this patch?
>
>    Merge x32 system calls with x86-64 system calls
>
>     Implemented with
>
>     1. Mark all x86-64 specific system calls with __NR_64_.
>     2. Mark all x32 specific system calls with __NR_x32_.
>     3. Include unistd_64_compat.h, instead of unistd_x32.h for kernel
>     build, which provides __NR_ versions of x86-64 specific system calls.
>     4. Append x32 specific system calls after the current x86-64 system
>     calls.
>     5. Generate unistd_x32.h from unistd_64.h, replacing __NR_x32_ with
>     _NR_.
>     6. Install user-space unistd_64.h, replacing __NR_64_ with _NR_.
>
> --
> H.J.
>



-- 
H.J.