bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error: can't resolve `.hcu.uncommon_code' {.hcu.uncommon_code sectio


From: Jim Wilson
Subject: Re: Error: can't resolve `.hcu.uncommon_code' {.hcu.uncommon_code section} - `.LFB17' {.text section}
Date: Mon, 23 Apr 2007 12:37:15 -0700

On Mon, 2007-04-23 at 09:34 -0700, Kristis Makris wrote:
> It seems that gcc does not even produce the inline assembly after the
> last goto, perhaps because it is deemed that it's dead code.

Seems right.

>  However, I
> need this assembly produced to emit the section change to ".text". Is
> there a way to tell gcc to NOT remove that inline assembly ? Is there
> some attribute/keyword that describes this ? I haven't found one.

There is no such option or attribute.  The problem here is that you are
doing things behind the compiler's back.  Long term, this isn't going to
work.  In the gcc docs, we mention that you aren't allowed to put
control flow (branches/labels) into extended asms.  GCC can't optimize
properly if it can't compute the control-flow graph.  Over time, the CFG
is getting more and more important for optimization, and programs that
violate this principle are more and more likely to fail.

> The only other alternative I see is to acquire the value of the
> hcu_wrapped_main_0_before label using the && operator

This is the only thing that occurred to me.  Make sure the label is used
somehow, and that prevents gcc from optimizing away dead code.  However,
over time, as gcc gets smarter, you will have to try harder to fool it
into believing that the label is actually used.  Simply using the label
in an extended asm may not be good enough, as gcc knows that asms aren't
allowed to contain branches.  You may need to store it in a static
variable, and add a goto *labeladdr someplace.

Note that use of &&label confuses the CFG, effectively disabling some
optimizations, which means that you may lose performance when you do
this.

I think you should rethink your whole approach.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com






reply via email to

[Prev in Thread] Current Thread [Next in Thread]