[Bug ada/89493] New: Stack smashing on armv7hl

2019-02-25 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89493

Bug ID: 89493
   Summary: Stack smashing on armv7hl
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel at zhukoff dot net
  Target Milestone: ---

Created attachment 45816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45816=edit
reproducer

Reporting this for ada as reproducer is part of gprbuild (gprinstall) code.

In some cases (return from exception handler) stack pointer is set to weird
value and either stack smashing protection or storage error occurs.

it's easy and 100% reproducible in Fedora linux distribution 
https://bugzilla.redhat.com/show_bug.cgi?id=1677173

gcc-9.0.1-0.4.fc30.armv7hl
gprbuild-2018-12.fc30.armv7hl

All other architectures (x86, s390x, ppc64le and aarch64 work fine)

We were able to strip reproducer to ~200 LOC (attached) 

# gprbuild -v -cargs:Ada -O2 -g


# valgrind ./exe/process
==29563== Memcheck, a memory error detector
==29563== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29563== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==29563== Command: ./exe/process
==29563== 
warning: file does not exist '/tmp/a/satrace.log'
==29563== Warning: client switching stacks?  SP change: 0xbdef07c0 --> 0x68818
==29563==  to suppress, use: --max-stackframe=1108836440 or greater
aaa
==29563== Invalid write of size 4
==29563==at 0x40C04: system__secondary_stack__ss_release (in
/tmp/test/exe/process)
==29563==  Address 0x68754 is 12 bytes inside data symbol
"ada_main__sec_default_sized_stacks"
==29563== 
==29563== Invalid read of size 4
==29563==at 0x1A09C: _ada_process (process.adb:119)
==29563==  Address 0x687ec is 164 bytes inside data symbol
"ada_main__sec_default_sized_stacks"
==29563== 
==29563== Invalid read of size 4
==29563==at 0x1A0A4: _ada_process (process.adb:119)
==29563==  Address 0xe1a02026 is not stack'd, malloc'd or (recently) free'd

[Bug ada/81424] [7 regression] internal error on GPRbuild with -O2

2017-07-16 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81424

--- Comment #2 from Pavel Zhukov  ---
(In reply to Eric Botcazou from comment #1)
> Confirmed, but how can it block anything since the workaround is trivial?

Thanks Eric.

We have to use compiler/linker flags provided by distribution's macros and they
include O2 [1]. While we can change gnat specific flags relatively easy global
optflags is distribution wide.

Ada packaging guidelines:
https://fedoraproject.org/wiki/Packaging:Ada

[1]  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
https://fedoraproject.org/wiki/Packaging:RPMMacros#Build_flags_macros_and_variables

[Bug ada/81424] New: gnat bugbox on i386

2017-07-13 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81424

Bug ID: 81424
   Summary: gnat bugbox on i386
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel at zhukoff dot net
  Target Milestone: ---

During compilcation of gprbuild or gnatcoll on i686 in Fedora compiler exits
with unrecoverable error [1]. 
Reproducer https://landgraf.fedorapeople.org/gccbug.tgz. Compilation options
are in command.sh file inside.
Fedora bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=1444614

It affects entire stack of Ada program in Fedora as all of them are blocked by
this.
As gcc<7 works fine and both gprbuild 2016 and 2017 from AdaCore cannot be
compiled with gcc>=7 I suspect the problem is in gcc itself not gprbuild.

[1] 
/builddir/build/BUILD/gprbuild-gpl-2017-src/gpr/src/gpr-compilation-protocol.ads:198:7:
note: 'PID' was declared here
+===GNAT BUG DETECTED==+
| 7.1.1 20170526 (Red Hat 7.1.1-2) (i686-redhat-linux) GCC error:  |
| in emit_move_insn, at expr.c:3698|
| Error detected around
/builddir/build/BUILD/gprbuild-gpl-2017-src/src/gprclean-main.adb:995:13|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

2017-03-08 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79945

--- Comment #6 from Pavel Zhukov  ---
Checked. Standard'Bit_Order is correct. So should be fine. Thank you, Eric.

[Bug ada/79945] ppc64le Default_Bit_Order in Ada

2017-03-07 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79945

Pavel Zhukov  changed:

   What|Removed |Added

 CC||pavel at zhukoff dot net

--- Comment #5 from Pavel Zhukov  ---
(In reply to Eric Botcazou from comment #1)

> Presumably:
> 
> Index: system-linux-ppc.ads
> ===
> --- system-linux-ppc.ads(revision 245767)
> +++ system-linux-ppc.ads(working copy)
> @@ -89,7 +89,8 @@ package System is
> --  Other System-Dependent Declarations
>  
> type Bit_Order is (High_Order_First, Low_Order_First);
> -   Default_Bit_Order : constant Bit_Order := High_Order_First;
> +   Default_Bit_Order : constant Bit_Order :=
> + Bit_Order'Val (Standard'Default_Bit_Order);
> pragma Warnings (Off, Default_Bit_Order); -- kill constant condition
> warning
>  
> --  Priority-related Declarations (RM D.1)

I'm wondering if it will work and not break ppc and ppc64.
ppc64le is exceptional in ppc family. ppc and ppc64 have high_bit_first 

$ gcc -dumpmachine
ppc64-redhat-linux

$ ./bits 
Default byte order is: HIGH_ORDER_FIRST
Order of record is HIGH_ORDER_FIRST

$ gcc -dumpmachine
ppc64le-redhat-linux
$ ./bits
Default byte order is: HIGH_ORDER_FIRST <== SHOULD BE LOW!
Order of record is LOW_ORDER_FIRST

[Bug ada/63222] Ada.Directories.Delete_File refuses to delete dangling symlinks

2015-07-22 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63222

--- Comment #2 from Pavel Zhukov pavel at zhukoff dot net ---
If symlink is broken Ada.Directories.Exists returns False (actually it's
because stat64 returns ENOENT in __gnat_stat). 

Easy to reproduce:
mkdir 'test'  cd 'test'  touch target  ln -s target link  rm target 
cd -  ./del

where del is:
with Ada.Directories;
procedure del is 
begin
  Ada.Directories.Delete_Tree (test);
end del; 


The problem is even worse if Ada.Direcotiries.Delete_Tree was called and
symlink's target was deleted before the symlink itself.
raised ADA.IO_EXCEPTIONS.USE_ERROR : directory tree rooted at .uuid could not
be deleted


[Bug ada/63222] Ada.Directories.Delete_File refuses to delete dangling symlinks

2015-07-22 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63222

Pavel Zhukov pavel at zhukoff dot net changed:

   What|Removed |Added

 CC||pavel at zhukoff dot net

--- Comment #1 from Pavel Zhukov pavel at zhukoff dot net ---
*** Bug 66972 has been marked as a duplicate of this bug. ***


[Bug ada/66972] New: Ada.Directories doesn't recognize dangling symlinks

2015-07-22 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66972

Bug ID: 66972
   Summary: Ada.Directories doesn't recognize dangling symlinks
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel at zhukoff dot net
  Target Milestone: ---

If symlink is broken Ada.Directories.Exists returns False (actually it's
because stat64 returns ENOENT in __gnat_stat). 

Easy to reproduce:
mkdir 'test'  cd 'test'  touch target  ln -s target link  rm target 
cd -  ./del

where del is:
with Ada.Directories;
procedure del is 
begin
  Ada.Directories.Delete_Tree (test);
end del; 


The problem is even worse if Ada.Direcotiries.Delete_Tree was called and
symlink's target was deleted before the symlink itself.
raised ADA.IO_EXCEPTIONS.USE_ERROR : directory tree rooted at .uuid could not
be deleted


The similar issue was reported already but closed with UNCONFIRMED:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63222


[Bug ada/66972] Ada.Directories doesn't recognize dangling symlinks

2015-07-22 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66972

Pavel Zhukov pavel at zhukoff dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Pavel Zhukov pavel at zhukoff dot net ---
Will update original report

*** This bug has been marked as a duplicate of bug 63222 ***


[Bug ada/65477] gnat is built with nodlopen

2015-03-20 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65477

--- Comment #1 from Pavel Zhukov pavel at zhukoff dot net ---
This patch works for me:
Build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=9275707

Patch:
diff --git a/gcc/ada/gcc-interface/Makefile.in
b/gcc/ada/gcc-interface/Makefile.in
index b552d3d..69d55aa 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -2818,14 +2818,14 @@ gnatlib-shared-default:
  gnatlib
$(RM) $(RTSDIR)/libgna*$(soext)
cd $(RTSDIR); `echo $(GCC_FOR_TARGET) \
-| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`
-shared -Wl,-z,nodlopen $(GNATLIBCFLAGS) \
+| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`
-shared -Wl,-z $(GNATLIBCFLAGS) \
$(PICFLAG_FOR_TARGET) \
-o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \
$(SO_OPTS)libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(MISCLIB) -lm
cd $(RTSDIR); `echo $(GCC_FOR_TARGET) \
-| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`
-shared -Wl,-z,nodlopen $(GNATLIBCFLAGS) \
+| sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'`
-shared -Wl,-z $(GNATLIBCFLAGS) \
$(PICFLAG_FOR_TARGET) \
-o libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \
$(GNATRTL_TASKING_OBJS) \


[Bug ada/65477] New: gnat is built with nodlopen

2015-03-19 Thread pavel at zhukoff dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65477

Bug ID: 65477
   Summary: gnat is built with nodlopen
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel at zhukoff dot net

Created attachment 35068
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35068action=edit
test program

It's not possible to write shared plugins in ada because libgnat (and only
libgnat from gcc) is built with nodlopen option.

Example:
Error: unable to load plugin ~/.weechat/plugins/liblibaweeplug.so:
libgnat-4.9.so: shared object cannot be dlopen()ed

How to reproduce:
Try to dlopen libgnat.so. dlopen returns NULL works fine for libc/libm/etc


[Bug ada/59382] New: gnatmake is not able to compile libraries on ARM (native)

2013-12-04 Thread pavel at zhukoff dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59382

Bug ID: 59382
   Summary: gnatmake is not able to compile libraries on ARM
(native)
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel at zhukoff dot net

Created attachment 31376
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31376action=edit
suggested patch

gnatmake is not able to build libraries (both static or dynamic) on arm
platform natively.

gcc-gnat-4.8.2-2.fc20.armv7hl

# gnatmake -P testso.gpr -f
testso.gpr:4:22: warning: libraries are not supported on this platform
gcc -c -I- -gnatA /root/testsolib/test.adb

== testso.gpr == 

library project testso is 
for source_dirs use (.);
for library_kind use relocatable;
for Library_Name use noname;
for Library_Dir use lib/;
end testso;

== test.ad? == 
any package; 


Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7hl-redhat-linux-gnueabi/4.8.2/lto-wrapper
Target: armv7hl-redhat-linux-gnueabi
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/home/max/rpm/BUILD/gcc-4.8.2-20131017/obj-armv7hl-redhat-linux-gnueabi/isl-install
--with-cloog=/home/max/rpm/BUILD/gcc-4.8.2-20131017/obj-armv7hl-redhat-linux-gnueabi/cloog-install
--disable-sjlj-exceptions --with-cpu=cortex-a8 --with-tune=cortex-a8
--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
--with-abi=aapcs-linux --build=armv7hl-redhat-linux-gnueabi
Thread model: posix
gcc version 4.8.2 20131017 (Red Hat 4.8.2-2) (GCC) 

# gnatmake --version
GNATMAKE 4.8.2 20131017 (Red Hat 4.8.2-2)
Copyright (C) 1995-2013, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


[Bug ada/56474] New: GNAT computes size of the object to be allocated incorrectly

2013-02-27 Thread pavel at zhukoff dot net


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



 Bug #: 56474

   Summary: GNAT computes size of the object to be allocated

incorrectly

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: ada

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: pa...@zhukoff.net





100% reproducible



Smaller reproducer:



with Ada.Streams;



package Pkg is

   use type Ada.Streams.Stream_Element_Offset;



   type Vector (Size : Ada.Streams.Stream_Element_Offset) is record

  Value : Ada.Streams.Stream_Element_Array (0 .. Size);

   end record;



   Empty_Vector : Vector (-1);



end Pkg;



with Pkg;

procedure Bbb is

begin

   null;

end Bbb;



$ gnatmake bbb

gcc -c bbb.adb

gcc -c pkg.ads

pkg.ads:10:04: warning: Storage_Error will be raised at run time

gnatbind -x bbb.ali

gnatlink bbb.ali



$ ./bbb



raised STORAGE_ERROR : object too large


[Bug ada/49783] GCC must bring ads and adb files after installation

2012-01-11 Thread pavel at zhukoff dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49783

--- Comment #3 from Pavel Zhukov pavel at zhukoff dot net 2012-01-11 10:36:18 
UTC ---
Created attachment 26298
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26298
list of files from gnat_util


[Bug ada/49783] GCC must bring ads and adb files after installation

2012-01-10 Thread pavel at zhukoff dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49783

--- Comment #2 from Pavel Zhukov pavel at zhukoff dot net 2012-01-10 18:22:02 
UTC ---
Hi Ludovic. 
Have your patches approved by upstream? 
I'm waiting for this because I cannot update gprbuild without correct sources
of GCC FSF... (libgnat, gnat_urils or smth else). Besides there are some issues
with aunit-2011 gcc-4.7 and gprbuild-2010


[Bug ada/49783] New: GCC must bring ads and adb files after installation

2011-07-19 Thread pavel at zhukoff dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49783

   Summary: GCC must bring ads and adb files after installation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pa...@zhukoff.net


For correct packaging some Ada programs (such as GprBuild, ASIS, Aunit, others)
they need to be  synchronized with Gnat (Gcc-gnat). But there are no any specs
or bodies files available after gcc installation. 

I've opened bug in Fedora bugzilla, but Jakub wont package sources without
upstream. https://bugzilla.redhat.com/722732 . We can use lib/gnat/gnat_util
from Gnat-gpl from Adacore for example.

Is it possible to install sources (ads and adb) to /usr/share/{something} or
/usr/include/{something} with make install (e.g. install_sources target)?