Having observed the bug while building a native, SJLJ version of
libgnat on x86_64, I have filed PR ada/34400 for this.
--
Ludovic Brenta.
Eric Botcazou wrote:
On the SPARC, this produced an executable I couldn't run
on the simulator. It looked like the .text segment may
have increased enough to not fit in the simulator.
Weird. The EH tables should probably not end up in .text.
RTEMS applications are statically linked
> FWIW. I see the same behavior for i386-unknown-netbsdelf3.1 too (when
> compiling natively, i.e. not using cross compiler).
For native platforms, I would suggest to switch to DWARF-2 EH, see for
example system-freebsd-x86.ads.
--
Eric Botcazou
> On the SPARC, this produced an executable I couldn't run
> on the simulator. It looked like the .text segment may
> have increased enough to not fit in the simulator.
Weird. The EH tables should probably not end up in .text.
> So this appears to work around the build time problem and
> will l
On Fri, 30 Nov 2007, Joel Sherrill wrote:
Krister Walfridsson wrote:
On Wed, 28 Nov 2007, Joel Sherrill wrote:
I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling
Eric Botcazou wrote:
Doing this fixed the long build time issue but it opened issue.
OK, thanks for confirming.
It looks like the RTEMS configuration is missing something
that this requires. The first application I tried to link is missing:
+ __gnat_eh_personality
+ __gnat_begin_han
> Doing this fixed the long build time issue but it opened issue.
OK, thanks for confirming.
> It looks like the RTEMS configuration is missing something
> that this requires. The first application I tried to link is missing:
>
> + __gnat_eh_personality
> + __gnat_begin_handler
> + __gnat_end_ha
Eric Botcazou wrote:
Thank you for confirming it wasn't just me or my configuration. This
looks like a serious issue to me.
It's partly your configuration, this presumably doesn't happen on platforms
that use DWARF-2 exception handling, i.e. most native platforms (I just
re-tested SPARC
> Thank you for confirming it wasn't just me or my configuration. This
> looks like a serious issue to me.
It's partly your configuration, this presumably doesn't happen on platforms
that use DWARF-2 exception handling, i.e. most native platforms (I just
re-tested SPARC/Solaris), probably why n
Krister Walfridsson wrote:
On Wed, 28 Nov 2007, Joel Sherrill wrote:
I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling on Linux x86 targeting the
PowerPC or SPARC
On Wed, 28 Nov 2007, Joel Sherrill wrote:
I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling on Linux x86 targeting the
PowerPC or SPARC leads to a huge compilation
Hi,
I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling on Linux x86 targeting the
PowerPC or SPARC leads to a huge compilation time
on a single file.
joel 27918 2
12 matches
Mail list logo
