From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-61766-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21287 invoked by alias); 16 Oct 2002 19:53:56 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 21267 invoked from network); 16 Oct 2002 19:53:55 -0000
Received: from unknown (HELO nile.gnat.com) (205.232.38.5)
  by sources.redhat.com with SMTP; 16 Oct 2002 19:53:55 -0000
Received: from gnat.com (darwin.gnat.com [205.232.38.44])
	by nile.gnat.com (Postfix) with ESMTP
	id C79B4F28D6; Wed, 16 Oct 2002 15:53:54 -0400 (EDT)
Date: Wed, 16 Oct 2002 13:28:00 -0000
Subject: Re: Problems building GNAT on OS X with top-of-tree
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v546)
Cc: gcc@gcc.gnu.org
To: Dale Johannesen <dalej@apple.com>
From: Geert Bosch <bosch@gnat.com>
In-Reply-To: <E5B21272-E13A-11D6-B07C-000393D76DAA@apple.com>
Message-Id: <DD3D5C3B-E140-11D6-A8D0-00039344BF4A@gnat.com>
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-10/txt/msg00990.txt.bz2


On Wednesday, Oct 16, 2002, at 15:10 America/New_York, Dale Johannesen 
wrote:
> OK, the problem is code that looks like this:
>
> .comm _ada__exceptions__subprogram_descriptors,8
>           ....
>         addis 
> r9,r31,ha16(_ada__exceptions__subprogram_descriptors-L42$pb)
>         lwz 
> r9,lo16(_ada__exceptions__subprogram_descriptors-L42$pb)(r9)
>
> This object looks like something the Ada FE created.
> .comm data must be addressed by the non_lazy_ptr mechanism:
>
> int x[20];
> main() { foo(x); }
>
>         addis r9,r31,ha16(L_x$non_lazy_ptr-L1$pb)
>         lwz r3,lo16(L_x$non_lazy_ptr-L1$pb)(r9)
> .comm _x,80
> .data
> .non_lazy_symbol_pointer
> L_x$non_lazy_ptr:
>         .indirect_symbol _x
>         .long   0
>
> The mechanism is in config/darwin.c and config/rs6000/rs6000.c.
> machopic_legitimize_pic_address is probably a good place to start.
>

OK, I see. Indeed, using -fno-common eliminates/suppresses the problem.
However, I don't see how the front end should have to know
about these details. I looked at darwin.c, and I see the implementation
of the scheme using lazy and non-lazy pointers, but there does not
seem to be any documentation at a sufficiently high level to be able
to understand what is going on there.

I'm focussing now on finding out why this problems does not occur with
the C front end, which seems to use the same method for outputting
variables in the common section.

   -Geert