headers
Jakub Jelinek | 22 May 2013 09:43
Picon
Favicon

Re: Porting libsanitizer to aarch64

On Wed, May 22, 2013 at 11:25:18AM +0400, Konstantin Serebryany wrote:
> > > Then arises a runtime problem: aarch64's frame grows upward which is
> > > not supported: how long would it take to develop this support if at
> > > all possible?
> >
> > Better do what all other targets that want to support -fstack-protector*
> > or -fsanitize=address, use frame grows downward if flag_stack_protector
> > || flag_asan.  You wouldn't have -fstack-protector* support otherwise
> > either.
> >
> 
> I would second that.
> Supporting upward-growing stack will introduce quite a bit of disruption in
> the run-time library and
> in both compiler modules (GCC and LLVM).

Frame grows upward isn't necessarily stack grows upward, the former is just
mostly compiler internal decision in which direction to allocate automatic
variables and later on spill slots, the latter is an ABI matter and AFAIK
only PA and stormy16 goes against all other architectures on that.
That said, at least for stack protector frame grows downward is a must,
because you don't want array overflows to clobber spill slots, thus spill
slots must go below arrays which are laid out earlier.

Changing frame grows upward into frame grows downward shouldn't be that
hard, see e.g. rs6000 port, where
#define FRAME_GROWS_DOWNWARD (flag_stack_protect != 0 || flag_asan != 0)
and grep the port where it uses FRAME_GROWS_DOWNWARD.
Basically you need to tweak initial elimination offset computation for it,
and that might be it, or perhaps one or two extra spots.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Konstantin Serebryany | 22 May 2013 09:26
Picon

Re: Porting libsanitizer to aarch64

[resending in plain text mode; arghh]

On Wed, May 22, 2013 at 11:25 AM, Konstantin Serebryany
<konstantin.s.serebryany <at> gmail.com> wrote:
> Hi Christophe,
>
> We would love to see the aarch64-specific changes in upstream repo
> (see https://code.google.com/p/address-sanitizer/wiki/HowToBuild).
> Once the changes are in the upstream svn, one of us will merge them to the
> gcc trunk.
>
> If you have some non-trivial concerns, please reach us at
> address-sanitizer <at> googlegroups.com
> My question to you would be: will it be possible to have a public build bot
> for aarch64?
> (W/o regular automated testing we will be breaking aarch64 every second day)
>
>
> On Tue, May 21, 2013 at 7:44 PM, Jakub Jelinek <jakub <at> redhat.com> wrote:
>>
>> On Tue, May 21, 2013 at 05:35:45PM +0200, Christophe Lyon wrote:
>> > I have been looking at enabling libsanitizer for aarch64 GCC compilers.
>> >
>> > To make the build succeed, I had to modify libsanitizer code:
>> > - some syscalls are not available on aarch64 (libsanitizer uses some
>> > legacy ones such as open, readlink, stat, ...)
>> > - unwinding code needs to be added.
>> >
>> > What's the way of discussing such patches? On GCC lists or elsewhere?
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oleg Smolsky | 21 May 2013 20:24
Favicon

gcc 4.8: broken headers when using gnu-versioned-namespace

Hey all, I've just built gcc 4.8 with 
--enable-symvers=gnu-versioned-namespace and compilation of a small test 
fails with the following:

In file included from /work/opt/gcc-4.8/include/c++/4.8.0/array:324:0,
                  from /work/opt/gcc-4.8/include/c++/4.8.0/tuple:39,
                  from 
/work/opt/gcc-4.8/include/c++/4.8.0/bits/stl_map.h:63,
                  from /work/opt/gcc-4.8/include/c++/4.8.0/map:61,
                  from ....................
/work/opt/gcc-4.8/include/c++/4.8.0/debug/array:296:12: error: 
‘tuple_size’ is not a class template
      struct tuple_size<__debug::array<_Tp, _Nm>>
...
...

It looks like include/c++/4.8.0/debug/array is missing a couple of wrappers:

_GLIBCXX_BEGIN_NAMESPACE_VERSION
_GLIBCXX_END_NAMESPACE_VERSION

IE it is a similar thing to this change:
     http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193584

Should I re-open the bug?

Oleg.
Permalink | Reply | 1 comment |
headers
Christophe Lyon | 21 May 2013 17:35
Favicon

Porting libsanitizer to aarch64

Hi,

I have been looking at enabling libsanitizer for aarch64 GCC compilers.

To make the build succeed, I had to modify libsanitizer code:
- some syscalls are not available on aarch64 (libsanitizer uses some
legacy ones such as open, readlink, stat, ...)
- unwinding code needs to be added.

What's the way of discussing such patches? On GCC lists or elsewhere?

Then arises a runtime problem: aarch64's frame grows upward which is
not supported: how long would it take to develop this support if at
all possible?

I have not looked at tsan in detail yet, it currently does not build
for aarch64 either.

Thanks,

Christophe.
Permalink | Reply | 1 comment |
headers
Andreas Krebbel | 21 May 2013 14:40
Picon

RFC: S/390 Transactional memory support - save/restore of FPRs

Hi,

I'm currently implementing support for hardware transactional memory
in the S/390 backend and ran into a problem with saving and restoring
the floating point registers.

On S/390 the tbegin instruction starts a transaction.  If a subsequent
memory access collides with another the transaction is aborted.  The
execution then continues *after* the tbegin instruction.  All memory
writes after the tbegin are rolled back, the general purpose registers
selected in the tbegin operand are restored, and the condition code is
set in order indicate that an abort occurred.  What the code then is
supposed to do is to check the condition code and either jump back to
the transaction if it is a temporary failure or provide an alternate
implementation using e.g. a lock.

Unfortunately our tbegin instruction does not save the floating point
registers leaving it to the compiler to make sure the old values get
restored.  This will be necessary if the abort code relies on these
values and the transaction body modifies them.

With my current approach I try to place FPR clobbers to trigger GCC
generating the right save/restore operations.  This has some
drawbacks:

- Bundling the clobbers with the tbegin causes FPRs to be restored
  even in the good path (the transaction never aborts).

- Placing the clobbers on the abort path kinda works. However it is
  not really correct.  GCC could decide to wrap the save/restore
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ard Biesheuvel | 21 May 2013 11:32
Favicon

ARM/AAarch64: NEON intrinsics in the kernel

Hello all,

I am currently exploring various ways of using NEON instructions in
kernel mode. One of the ways of doing so is using NEON intrinsics,
which we would like to support in the kernel, but unfortunately, at
the moment we can't because the support header arm_neon.h assumes C99
conformance and includes <stdint.h>. The kernel does not supply that
header.

As far as I can tell, the only dependency arm_neon.h has on the
contents of that header are the [u]int[8|16|32|64]_t typedefs. The
kernel does define those, only in a different header.

I would like to propose the following way to address this issue: as
arm_neon.h is coupled very tightly with GCC's internals
(__builtin_neon_* types and functions), could we not modify arm_neon.h
to
- drop the #include <stdint.h>
- replace every instance of [u]intxx_t with the builtin macro
__[U]INTxx_TYPE__ (as we are already dependent on specific versions of
GCC, this should not introduce any additional limitations)

In this way, it is much easier to support NEON intrinsics in
environments that we care about (like the kernel) but do not conform
to the standards.

Kind regards,
Ard.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bin.Cheng | 21 May 2013 07:50
Picon

Question on operand_equal_p on different type conversion expressions

Hi,
I ran into a call of operand_equal_p for two type conversion tree nodes like:
arg0:
 <nop_expr 0xb737a974
    type <integer_type 0xb74faae0 public unsigned HI
        size <integer_cst 0xb74e87c4 constant 16>
        unit size <integer_cst 0xb74e87e0 constant 2>
        align 16 symtab 0 alias set -1 canonical type 0xb74faae0
precision 16 min <integer_cst 0xb74e8b28 0> max <integer_cst
0xb74e8a64 65535>>

    arg 0 <ssa_name 0xb73222f8
        type <integer_type 0xb74fa420 long int sizes-gimplified public SI
            size <integer_cst 0xb74e855c constant 32>
            unit size <integer_cst 0xb74e8578 constant 4>
            align 32 symtab 0 alias set 5 canonical type 0xb74fa420
precision 32 min <integer_cst 0xb74e8888 -2147483648> max <integer_cst
0xb74e88a4 2147483647> context <translation_unit_decl 0xb76a7d80
D.6120>
            pointer_to_this <pointer_type 0xb75017e0>>
        visiteddef_stmt _23 = *_22;

        version 23>>

arg1:
 <convert_expr 0xb737a3e8
    type <integer_type 0xb74fa2a0 short int sizes-gimplified public HI
        size <integer_cst 0xb74e87c4 constant 16>
        unit size <integer_cst 0xb74e87e0 constant 2>
        align 16 symtab 0 alias set 4 canonical type 0xb74fa2a0
(Continue reading)

Permalink | Reply | 4 comments |
headers
Basile Starynkevitch | 20 May 2013 16:31

libbacktrace & plugins....

Hello All,

Currently (for GCC 4.8 at least) when a plugin crashes (ie. SIGSEGV) libbacktrace is apparently not able 
to show backtrace information inside the plugin[s].

I believe that, at least on GNU/Linux wich has dladdr, it would be nice to extend libbacktrace 
to show backtrace information inside plugins (at least those compiled with -g).

Is is reasonably feasible? I'm not familiar with libbacktrace, but (since MELT would be very happy with
that) 
I might perhaps help....

Cheers.
--

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Permalink | Reply | 2 comments |
headers
gccadmin | 20 May 2013 00:39
Picon
Favicon

gcc-4.9-20130519 is now available

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

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

You'll find:

 gcc-4.9-20130519.tar.bz2             Complete GCC

  MD5=b05ffe5b390fdfab7ab5066c20f00b57
  SHA1=dcebb2530fbe628f9ddc4a7bf945724c7b1f74ac

Diffs from 4.9-20130512 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 19 May 2013 19:30
Picon

Crashes inside libgcc_s_dw2-1.dll

[Please CC me on replies, as I'm not a subscriber.]

Would someone on the developers' team please comment on this problem:

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00413.html

In a nutshell, loading a GnuTLS DLL by a MinGW compiled Emacs causes
libintl DLL to be loaded, and if that libintl DLL in turns loads
libgcc_s_dw2-1.dll, the program crashes inside libgcc on exit, when
the runtime unloads all the DLLs loaded by Emacs.  A related
discussion on the MinGW mailing list

  https://sourceforge.net/mailarchive/message.php?msg_id=30633081

Suggests that this is a general problem with DLLs linked against a
shared libgcc that uses dw2 unwinding.

Is there a bug in libgcc's dw2 unwinding code?  Is it a fundamental
mistake to build DLLs that depend on libgcc as a shared library?  Or
are the applications using libgcc_s_dw2-1.dll buggy and need to get
their act together in some way (if so, how)?  Or anything else?

Thanks in advance.
Permalink | Reply | 6 comments |
headers
gccadmin | 19 May 2013 00:40
Picon
Favicon

gcc-4.7-20130518 is now available

Snapshot gcc-4.7-20130518 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20130518/
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/branches/gcc-4_7-branch revision 199069

You'll find:

 gcc-4.7-20130518.tar.bz2             Complete GCC

  MD5=65f65055e2554cf2e5fe3bd638a2f450
  SHA1=4b46508f167e797a66ac1307efd619c6a7195bec

Diffs from 4.7-20130511 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.
Permalink | Reply | 0 comments |

Gmane