--enable-gnu-unique-object --with-abi=mx32
--with-fpmath=sse
Thread model: posix
gcc version 5.0.0 20150122 (experimental) (GCC)
[hjl@gnu-tools-1 gcc-x32-mx32]$
Either will produce GCC which support -mx32. x86_64-linux-gnux32 isn't
required to configure
GCC.
--
H.J.
Various Maintainers
>> > section?
>>
>> I understand Jeff's email as a pre-approval of such a patch.
>
> I think only SC can appoint maintainers, and while Jeff is in the SC,
> my reading of that mail wasn't that it was the SC that has acked that, but
> rather a question if Igor is willing to take that role, which then would
> need to be acked by SC.
>
Where are we on this? Do we have a maintainer for Cilk Plus
and its run-time library?
--
H.J.
uld be 8 on
> x86_64 GNU/Linux, because traditionally, that's what mallocs implement
> for this architecture. (dlmalloc in glibc is an exception.)
>
x86-64 psABI specifies that a memory >= 16 bytes is 16-byte aligned.
If malloc doesn't do it, it is a broken.
--
H.J.
On Thu, Apr 2, 2015 at 4:08 AM, Florian Weimer wrote:
> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer wrote:
>>> On 04/02/2015 10:40 AM, Andrew Haley wrote:
>>>
>>>> So, max_align_t is an object type, and therefore
On Thu, Apr 2, 2015 at 4:17 AM, Florian Weimer wrote:
> On 04/02/2015 01:13 PM, H.J. Lu wrote:
>> On Thu, Apr 2, 2015 at 4:08 AM, Florian Weimer wrote:
>>> On 04/02/2015 01:06 PM, H.J. Lu wrote:
>>>> On Thu, Apr 2, 2015 at 1:46 AM, Florian Weimer wrote:
>&g
and 4.0 kernels are affected.
3.19.5-100/3.19.5-200 from Fedora 20/21 fix the bug.
--
H.J.
On Wed, Apr 22, 2015 at 6:10 AM, Jakub Jelinek wrote:
> On Wed, Apr 22, 2015 at 05:40:07AM -0700, H.J. Lu wrote:
>> On Wed, Apr 22, 2015 at 5:19 AM, Jakub Jelinek wrote:
>> > On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote:
>> >> Is anyone else seein
ones correctly.
Comments, suggestions?
Thanks.
--
H.J.
On Mon, May 11, 2015 at 8:48 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 11 May 2015, H.J. Lu wrote:
>
>> To remove one direct branch to PLT for external function calls:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg1.html
>>
>> I am proposing to
FYI,
https://groups.google.com/forum/#!topic/ia32-abi/cn7TM6J_TIg
--
H.J.
On Mon, May 11, 2015 at 8:55 AM, H.J. Lu wrote:
> FYI,
>
> https://groups.google.com/forum/#!topic/ia32-abi/cn7TM6J_TIg
>
I am adding Intel MCU psABI support into binutils. This is the
first patch.
--
H.J.
---
bfd/
* elfcode.h (elf_object_p): Replace EM_486 with EM_IAMC
On Mon, May 11, 2015 at 8:52 AM, H.J. Lu wrote:
>
> I will clarify in the spec language. Yes, that is the intention for both
> R_X86_64_RELAX_PC32 and R_X86_64_RELAX_PLT32. That is what
> is implemented on users/hjl/relax branch.
>
Here is the updated proposal. I changed nop p
eaning (even if only affecting performance, not correctness). Is
> it anywhere publicly stated that the address size override will
> continue to be ignored?
I will ask to put it in Intel SDM.
--
H.J.
On Tue, May 12, 2015 at 11:42 AM, H.J. Lu wrote:
> On Mon, May 11, 2015 at 8:52 AM, H.J. Lu wrote:
>>
>> I will clarify in the spec language. Yes, that is the intention for both
>> R_X86_64_RELAX_PC32 and R_X86_64_RELAX_PLT32. That is what
>> is implemente
On Mon, May 18, 2015 at 5:45 AM, Michael Matz wrote:
> Hi,
>
> On Sun, 17 May 2015, H.J. Lu wrote:
>
>> To remove one direct branch to PLT for external function calls:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg1.html
>>
>> I am proposing to
NMENT?
--
H.J.
On Thu, May 21, 2015 at 1:56 PM, Jim Wilson wrote:
> On 05/20/2015 10:00 AM, H.J. Lu wrote:
>> By default, alignment of DImode and DFmode is set to 8 bytes.
>> Intel MCU psABI specifies alignment of DImode and DFmode
>> to be 4 bytes. I'd like to make get_mode_alignmen
On Thu, May 21, 2015 at 2:08 PM, H.J. Lu wrote:
> On Thu, May 21, 2015 at 1:56 PM, Jim Wilson wrote:
>> On 05/20/2015 10:00 AM, H.J. Lu wrote:
>>> By default, alignment of DImode and DFmode is set to 8 bytes.
>>> Intel MCU psABI specifies alignment of DImode and DF
On Thu, May 21, 2015 at 2:25 PM, H.J. Lu wrote:
> On Thu, May 21, 2015 at 2:08 PM, H.J. Lu wrote:
>> On Thu, May 21, 2015 at 1:56 PM, Jim Wilson wrote:
>>> On 05/20/2015 10:00 AM, H.J. Lu wrote:
>>>> By default, alignment of DImode and DFmode is set to 8 bytes.
On Thu, May 21, 2015 at 2:40 PM, H.J. Lu wrote:
> On Thu, May 21, 2015 at 2:25 PM, H.J. Lu wrote:
>> On Thu, May 21, 2015 at 2:08 PM, H.J. Lu wrote:
>>> On Thu, May 21, 2015 at 1:56 PM, Jim Wilson wrote:
>>>> On 05/20/2015 10:00 AM, H.J. Lu wrote:
>>>
ata, and thus the linker
> and dynamic linker must ensure that pointer equality is maintained. Which
> results in branch-to-branch-(to-branch) situations.
>
Your test exposed a linker bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=18458
I checked in this patch to fix it.
--
H.J.
--
for which LTO is both overkill and unworkable.
>
> This does leave open other optimization questions, mostly around weak
> functions. Consider constructs like
>
> if (foo) foo();
>
> Do we, within the compiler, try to CSE GOTPCREL and GOTPLTPCREL, accepting the
> possibility (not certainty) of jump-to-jump but definitely avoiding a separate
> load insn and the latency implied by that?
>
>
> Comments?
>
>
> r~
--
H.J.
Adding ia32/x86-64 psABI.
On Wed, May 27, 2015 at 5:44 PM, H.J. Lu wrote:
> On Wed, May 27, 2015 at 1:03 PM, Richard Henderson wrote:
>> There's one problem with the couple of patches that I've seen go by wrt
>> eliding
>> PLTs with -z now, and rela
On Thu, May 28, 2015 at 8:29 AM, Richard Henderson wrote:
> On 05/28/2015 04:27 AM, H.J. Lu wrote:
>> You get consecutive jmpq's because x86 PLT entry is used as the
>> canonical function address. If you compile main with -fno-plt -fPIE, you
>> get:
>
> Well, duh
On Thu, May 28, 2015 at 9:02 AM, Jakub Jelinek wrote:
> On Thu, May 28, 2015 at 08:52:28AM -0700, Richard Henderson wrote:
>> On 05/28/2015 08:42 AM, H.J. Lu wrote:
>> > On Thu, May 28, 2015 at 8:29 AM, Richard Henderson wrote:
>> >> On 05/28/2015 04:27 AM,
; to search for commands related to "word"...
Reading symbols from main...done.
(gdb) r
Starting program: /export/home/hjl/bugs/binutils/pr18458/main
PASS
[Inferior 1 (process 10663) exited normally]
Missing separate debuginfos, use: debuginfo-install glibc-2.18-19.2.fc20.x86_64
(gdb) b b
Breakpoint 1 at 0x77bf75f0: file b.c, line 5.
(gdb) r
Starting program: /export/home/hjl/bugs/binutils/pr18458/main
Breakpoint 1, b () at b.c:5
5 a();
(gdb) si
a () at a.c:5
5 printf("PASS\n");
(gdb)
--
H.J.
On Fri, May 29, 2015 at 10:59 AM, H.J. Lu wrote:
> On Fri, May 29, 2015 at 8:38 AM, Richard Henderson wrote:
>> On 05/28/2015 01:36 PM, Rich Felker wrote:
>>> On Thu, May 28, 2015 at 09:40:57PM +0200, Jakub Jelinek wrote:
>>>> On Thu, May 28, 2015 at 03:29
ag or configure
> option to switch
> the new interface off if not supported (maybe automatically based on the
> math.h header).
>
> Wilco
--
H.J.
).
>
> figure 3.4 pp23 does not clarify xmm* use for vector return at all - only
> mentioning floating point.
>
> = status
>
> In any event, GCC passes the vec32 return in memory,
> LLVM conversely passes it in xmm0:1 (at least for the versions I’ve tried).
>
> which leads to an ABI discrepancy when GCC is used to build code on systems
> based on LLVM.
>
> Please could the X86 maintainers clarify the intent (and maybe consider
> enhancing the footnote classification notes to make things clearer)?
>
> - and then we can figure out how to deal with the systems that are already
> implemented - and how to move forward.
>
> (as an aside, in any event, it seems inefficient to pass through memory when
> at least xmm0:1 are already set aside for return value use).
Please open a bug to keep track.
Thanks.
--
H.J.
t;, a separate pattern is required.
> Since an argument can be either negated or not, and we can use three
> logic ops (or, and, xor) there would be 72 patterns. So maybe a new
> optimization pass would be easier to create and maintain? (Just a silly
> guess.)
>
> I'd be grateful for any comments and advice.
>
> best regards
> Wojciech
>
> [1] https://github.com/WojciechMula/ternary-logic
Please open a gcc bug:
https://gcc.gnu.org/bugzilla/
and CC me. We will look into it.
Thanks.
--
H.J.
gt; P3 25 - 3
> P4 165
> P5 24
> --- ---
> Total P1-P3 229 + 3
> Total 418 + 3
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2019-02/msg00027.html
--
H.J.
R 89980) makes me wonder
> if it is, in fact, safe. I can see the broken bootstrap today
> in a clean build yet the bootstrap I did just before checking
> in the change went fine.
>
You need to do a clean bootstrap.
--
H.J.
e if this email goes through the machines that are having problems
> it may not get anywhere
>
Yes, I have the same problem.
--
H.J.
ments?
--
H.J.
On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy wrote:
> On 05/07/17 16:38, H.J. Lu wrote:
>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
>> GCCs older than GCC 4.9.4:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
>>
&
On Wed, Jul 5, 2017 at 8:51 AM, Carlos O'Donell wrote:
> On 07/05/2017 11:38 AM, H.J. Lu wrote:
>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled by
>> GCCs older than GCC 4.9.4:
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5806
On Wed, Jul 5, 2017 at 9:27 AM, Florian Weimer wrote:
> On 07/05/2017 06:21 PM, H.J. Lu wrote:
>> On Wed, Jul 5, 2017 at 9:18 AM, Florian Weimer wrote:
>>> On 07/05/2017 06:17 PM, H.J. Lu wrote:
>>>> On Wed, Jul 5, 2017 at 9:09 AM, Florian Weimer wrote:
>>
On Thu, Jul 6, 2017 at 1:06 AM, Szabolcs Nagy wrote:
> On 05/07/17 17:18, H.J. Lu wrote:
>> On Wed, Jul 5, 2017 at 8:53 AM, Szabolcs Nagy wrote:
>>> On 05/07/17 16:38, H.J. Lu wrote:
>>>> On x86-64, __tls_get_addr has to realigns stack so that binaries compiled
&g
lib
--enable-libmpx --with-multilib-list=m32,m64,mx32
--enable-linker-build-id --enable-gnu-unique-object --with-abi=mx32
--with-fpmath=sse
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
I didn't use --build=x86_64-pc-linux-gnux32
--
H.J.
On Mon, Aug 14, 2017 at 12:35 AM, Daniel Santos wrote:
> On 08/13/2017 07:05 PM, H.J. Lu wrote:
>> On Sun, Aug 13, 2017 at 3:52 PM, Daniel Santos
>> wrote:
>>> I've setup an x32 test environment using Gentoo in hopes of being able
>>> to both compile and
?
--
H.J.
On Tue, Aug 15, 2017 at 5:43 PM, Daniel Santos wrote:
> On 08/15/2017 06:18 AM, Richard Biener wrote:
>> On Mon, Aug 14, 2017 at 5:23 PM, H.J. Lu wrote:
>>> For GCC 8, when --enable-checking=yes,rtl is used with x32 GCC,
>>> I got
>>>
>>> cc1plus: ou
errors when Fedora or OpenSUSE upgrades to a more recent
> DejaGNU in the 1.6 series.
>
I am running Fedora 26 with dejagnu-1.6-2.fc26. What should I
look for?
--
H.J.
On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn wrote:
> On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu wrote:
>> On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn wrote:
>>> FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite. The GCC
>>> Testsuite uses "uns
neral. However, I still expect this to be
> very useful.
>
> Any comments or suggestions?
>
> Best regards,
> Jürg
Can you use __attribute__ ((scalar_storage_order)) in GCC 7?
--
H.J.
P19 - 5
> P2 134 - 27
> P3 108 - 55
> P4 161 + 27
> P5 27
> --- ---
> Total P1-P3 251 - 87
> Total 355 - 60
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2017-11/msg00134.html
--
H.J.
)
> [710507.530704] md/raid:md3: read error corrected (8 sectors at 132125792 on
> sdi1)
>
It took a long time to do "svn ci".
--
H.J.
th __x86_indirect_thunk_reg, linker can convert call
via GOT to direct branch if function is locally defined:
https://groups.google.com/forum/#!topic/x86-64-abi/eED5lzn3_Mg
H.J.
at the top of the stack, like this:
>
> __x86_indirect_thunk_rax:
> .LFB2:
> .cfi_startproc
> call.LIND5
> .LIND4:
> pause
> lfence
> jmp .LIND4
> .LIND5:
> .cfi_def_cfa_offset 16
> mov %rax, (%rsp)
> ret
> .cfi_endproc
>
> The unwinder should then use the other return address, from the caller of
> the thunk routine.
Can you open a GCC bug to track it?
Thanks.
--
H.J.
ult version.
> Is there any way for me to force the version for these symbols aswell?
> I'm aware that I can disable the whole mechanism with -freestanding, but I
> don't want to cripple the optimiser.
I think this is related to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
--
H.J.
n symbol,
There is no need for PLT since hidden symbol is defined locally. But
GCC ignores hidden visibility for libcalls, like memcpy. If GCC treats
them like normal calls, your scheme and my testcase should work.
> But anyway, doesn't matter terribly much if I understand :p
>
>
, bringing up an existing bug
> takes an entire minute.
>
Same here. When I opened a new bug today, it timed out. I had to look up
the database to see if I opened it or not.
--
H.J.
by adding "-static"
Why not adding "-static-pie" instead of "-static"?
> to my builds, produce static-pie binaries. But at the moment, that
> attempts to add an interp section.
>
> So my question is, if no conflicting options are found, why not hoist
> "-static -pie" to "-static-pie" ?
>
> Regards,
> Cory
--
H.J.
On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields wrote:
> On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu wrote:
>> On Tue, Jan 30, 2018 at 10:26 AM, Cory Fields wrote:
>>> Hi list
>>>
>>> I'm playing with -static-pie and musl, which seems to be in good shape
&g
On Tue, Jan 30, 2018 at 11:18 AM, Cory Fields wrote:
> On Tue, Jan 30, 2018 at 2:14 PM, H.J. Lu wrote:
>> On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields wrote:
>>> On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu wrote:
>>>> On Tue, Jan 30, 2018 at 10:26 AM, Cor
command-line, you
1. Remove -static and -pie.
2. Add -static-pie.
> for static before static-pie ?
>
--
H.J.
On Wed, Jan 31, 2018 at 7:56 AM, H.J. Lu wrote:
> On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields wrote:
>> After looking at this for quite a while, I'm afraid I'm unsure how to
>> proceed.
>>
>> As of now, static and static-pie
gt; openmp-simd and I always get a call to _ZGVbN2v_sin. Is there anyway
> to stop the use of the vectorized calls (without turning off -Ofast)?
Have you tried -lm?
--
H.J.
. _Unwind_ForcedUnwind_Phase2 sets frames to 1 for
_URC_NO_REASON_CANCEL
BTW, I opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85086
--
H.J.
On Mon, Mar 26, 2018 at 11:31 PM, Florian Weimer wrote:
> On 03/27/2018 12:43 AM, H.J. Lu wrote:
>>
>> On Linux, when alternate signal stack is used with thread cancellation,
>> _Unwind_Resume fails when it tries to unwind shadow stack from signal
>> handler on alterna
-10/msg01741.html
I also opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85086
I have a patch at
https://github.com/hjl-tools/gcc/commit/e9ff815941406e38fa629947af4d809b9129e860
which requires unwind ABI extension.
I'd like to see them fixed to get working Intel CET support in
GCC 8.
Thanks.
--
H.J.
On Tue, Mar 27, 2018 at 8:43 AM, Florian Weimer wrote:
> On 03/27/2018 01:26 PM, H.J. Lu wrote:
>
>> 2. Since shadow stack is never saved and restored by compiler, unwinder
>> in libgcc counts how many stack frame it has to unwind and uses INCSSP
>> to pop shadow stack
On Tue, Mar 27, 2018 at 8:55 AM, H.J. Lu wrote:
> On Tue, Mar 27, 2018 at 8:43 AM, Florian Weimer wrote:
>> On 03/27/2018 01:26 PM, H.J. Lu wrote:
>>
>>> 2. Since shadow stack is never saved and restored by compiler, unwinder
>>> in libgcc counts how many stac
y.
> In Fedora it will not make a difference, as the whole distro is
> built with -mcet -fcf-protection on i?86/x86_64.
>
I submitted a patch to add -mnop to enable multi-byte NOP code
generation which can be used with -fcf-protection to implement
indirect branch and return address tracking without -mcet:
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00868.html
--
H.J.
er, CVS did not have that).
>
You get revision number only with contrib/gcc_update and not
everyone uses it. See:
http://gcc.gnu.org/ml/gcc-testresults/2011-01/
I primarily use GIT mirror which doesn't use subversion number.
--
H.J.
should, but some work is needed at the binutils end. I am testing
> the attached two patches at the moment; the idea is to have fully-debugged
> support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it comes
> out.
>
FWIW, your recan linker patch doesn't fix LTO 8, which is:
http://sourceware.org/bugzilla/show_bug.cgi?id=12277
--
H.J.
On Tue, Feb 1, 2011 at 9:52 AM, Dave Korn wrote:
> On 01/02/2011 17:15, H.J. Lu wrote:
>> On Tue, Feb 1, 2011 at 2:54 AM, Dave Korn wrote:
>>> On 01/02/2011 02:33, Joel Sherrill wrote:
>>>> Hi,
>>>>
>>>> There are ~100 failures on each *-r
On Tue, Feb 1, 2011 at 10:39 AM, Dave Korn wrote:
> On 01/02/2011 18:01, H.J. Lu wrote:
>
>>>> FWIW, your recan linker patch doesn't fix LTO 8, which is:
>>>>
>>>> http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>>> It wasn't su
hat
> intentional, I was trying to keep the svn commit history, but I will
> stop doing that if it's an issue.
>
> I'll remove the PR references next time. Thanks for the heads up.
Git can solve this problem for you.
--
H.J.
On Wed, Feb 2, 2011 at 10:52 AM, Diego Novillo wrote:
> On Wed, Feb 2, 2011 at 13:48, H.J. Lu wrote:
>
>> Git can solve this problem for you.
>
> It was git the cause of the problem, actually. I committed with 'git
> svn dcommit' without squashing the commits in
ment D.3453_2 = data;
>
> It seems that for some reason, the pass claims to be able to
> eliminate all statements that take the address of "data",
> but then leaves the MEM reference unchanged ...
>
> Any suggestions on what might cause this problem?
>
This behavior change of -fno-strict-aliasing is caused by
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00788.html
--
H.J.
.
--
H.J.
sue.
> Is stack alignment to 16 bytes beneficial for X32?
>
Even ia32 uses 16byte stack alignment and we will make it
official soon via an amendment to the i386 psABI.
--
H.J.
It works. Please check out the x32 kernel to take a look.
> Maybe it's me, but I expected X32 to be the X86-64 ABI with 32-bit longs
> and pointers (converted to 64-bit arguments when passed in register or
> on the stack). That allows the same syscall argument marshalling that
> currently exists but just need a different set of syscall vectors.
>
That is exactly what we implemented.
--
H.J.
ent Hotspot, LuaJIT, and probably some more).
Please check out the x32 kernel source and provide feedback.
--
H.J.
ersion), and even GDB would
> mostly worked unchanged.
>
Yes, strace needs to be updated. I have ported GDB to x32.
--
H.J.
> If you want to make x32 closer to i386, I don't see the point. Why
> would it be problematic if it was as close to i386 as, say, armel?
>
We are providing a 32bit API with 64bit registers. Current APIs support
either 32bit or 64bit. I am not talking about pointer or long. I am talking
other types, like time_t, off_t, ..., defined by API. Adding another API
is extremely difficult.
--
H.J.
c would be pretty thin.
x32 is the same 64bit kernel interface for system calls which takes 64bit
arguments. You can pass either 32bit or 64bit value to them.
--
H.J.
2011/2/13 Petr Baudis :
> On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
>> > * H. J. Lu:
>> >
>> >>> Actually, I'm wondering if you can do the translation in user space.
>&
On Sun, Feb 13, 2011 at 12:10 PM, Arnd Bergmann wrote:
> On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
>> Hi,
>>
>> We made lots of progresses on x32 pABI:
>>
>> https://sites.google.com/site/x32abi/
>>
>> 1. Kernel interface with syscall is
On Sun, Feb 13, 2011 at 1:16 PM, H. Peter Anvin wrote:
> On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>> The basic concept looks entirely reasonable to me, but I'm
>>> curious what drove the decision to start out with the x86_64
>>> system calls instead of the g
On Sun, Feb 13, 2011 at 2:03 PM, H. Peter Anvin wrote:
> On 02/13/2011 01:28 PM, H.J. Lu wrote:
>>
>> That is is currently implemented on hjl/x32 branch.
>>
>> I also added
>>
>> __NR_sigaction
>> __NR_sigpending
>> __NR_sigprocmask
&g
generic syscall numbers,
> even if you keep the i386 data structures.
>
x32 system call number is BASE + 64bit system call number. It is
easy to keep 64bit and x32 in sync.
--
H.J.
> It's a simple question - why do we care, why do we want the overhead and
> the hassle, what do users get in return ?
>
The real question is if we need to use ia32. If the answer is yes, then
x32 provides the benefit of ia32 with register extended to 64bit plus 8
more registers as well as IP relative address.
--
H.J.
On Sat, Feb 12, 2011 at 11:41 AM, H.J. Lu wrote:
> Hi,
>
> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
> 2. GCC x32 branch is stabilizing.
> 3. The Bionic C library wo
Hi,
I updated x32 psABI draft to version 0.2 to change x32 library path
from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
Ubuntu and other derivative distributions. The new x32 psABI is
available from:
https://sites.google.com/site/x32abi/home
--
H.J.
layer to provide our syscall
>> table, since we don't have a traditional compatibility layer in this mode
>> (unlike x86_64 and i386).
>
> This sounds more like MIPS' n32 than x32 really.
>
Yes, x32 can access the full 4GB address space. There are some
additional optimizations which can be done in x32, but not in x86-64
small model.
--
H.J.
On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu wrote:
> Hi,
>
> I updated x32 psABI draft to version 0.2 to change x32 library path
> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
> Ubuntu and other derivative distributions. The new x32 psABI is
> availab
On Thu, Feb 17, 2011 at 12:35 AM, Jan Beulich wrote:
>>>> On 16.02.11 at 21:04, "H. Peter Anvin" wrote:
>> On 02/16/2011 11:22 AM, H.J. Lu wrote:
>>> Hi,
>>>
>>> I updated x32 psABI draft to version 0.2 to change x32 library path
>>
On Thu, Feb 17, 2011 at 7:22 AM, Jan Hubicka wrote:
>> On Thu, Feb 17, 2011 at 08:35:26AM +, Jan Beulich wrote:
>> > >>> On 16.02.11 at 21:04, "H. Peter Anvin" wrote:
>> > > On 02/16/2011 11:22 AM, H.J. Lu wrote:
>> > >> Hi,
>&g
LA only. If x86-64 ABI was REL+RELA like EABI is, we
> would not have this problem here.
>
If people want to see REL+RELA in x32, they have to contribute codes.
--
H.J.
On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich wrote:
>>>> On 17.02.11 at 16:49, "H.J. Lu" wrote:
>> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka wrote:
>>>> > According to Mozilla folks however REL+RELA scheme used by EABI leads
>
On Fri, Feb 18, 2011 at 12:11 AM, Jan Beulich wrote:
>>>> On 17.02.11 at 18:59, "H.J. Lu" wrote:
>> On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich wrote:
>>>>>> On 17.02.11 at 16:49, "H.J. Lu" wrote:
>>>> On Thu, Feb 17, 2011
On Wed, Feb 16, 2011 at 9:45 PM, H.J. Lu wrote:
> On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu wrote:
>> Hi,
>>
>> I updated x32 psABI draft to version 0.2 to change x32 library path
>> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>
On Fri, Feb 18, 2011 at 8:28 PM, H.J. Lu wrote:
> On Wed, Feb 16, 2011 at 9:45 PM, H.J. Lu wrote:
>> On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu wrote:
>>> Hi,
>>>
>>> I updated x32 psABI draft to version 0.2 to change x32 library path
>>> from
133151crafty.64
173535 1656410689161259015 133607
crafty.x32
H.J.
---
On Sat, Feb 19, 2011 at 11:23 AM, Xinliang David Li wrote:
> This shows how important ilp32 is for some applications. It would be good to
> show the impact of larger register set. Candidat
On Mon, Feb 21, 2011 at 12:04 AM, Jan Beulich wrote:
>>>> On 18.02.11 at 18:53, "H.J. Lu" wrote:
>> How about only allowing REL relocations in executables and DSOes?
>
> That'd be at least part of it, but I'd still prefer not forbidding them
> altog
Hi,
Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
https://sites.google.com/site/x32abi/
The major remaining issues are glibc/gcc testsuite failures,
kernel core dump and signal handler unwind.
--
H.J.
-flto. Any
>> ideas why?
>
> It's probably a bug. You're probably the first to try it.
>
It may be related to
http://sourceware.org/ml/binutils/2011-01/msg00108.html
My lto-mixed branch has some support for linker scripts.
--
H.J.
On Sun, Mar 6, 2011 at 6:52 AM, Anthony Green wrote:
> On 3/6/2011 9:10 AM, H.J. Lu wrote:
>>
>> On Sun, Mar 6, 2011 at 5:57 AM, Dave Korn
>> wrote:
>>>
>>> On 06/03/2011 07:02, Anthony Green wrote:
>>>>
>>>> All of the -flto
201 - 300 of 1206 matches
Mail list logo
