[Bug ld/4409] New: --unresolved-symbols=ignore-all issues on ia64
cat > a.c
[Bug binutils/4412] New: windres is not 64bit are
Windres doesn't work if cross compiled on a 64bit system, I've made a patch that may have a also uneeded changes, but at least it works. It needs stdint.h I hope all the changes are enough -- Summary: windres is not 64bit are Product: binutils Version: 2.17 Status: NEW Severity: critical Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: sherpya at netfarm dot it CC: bug-binutils at gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: i586-pc-mingw32msvc http://sourceware.org/bugzilla/show_bug.cgi?id=4412 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4412] windres is not 64bit are
--- Additional Comments From sherpya at netfarm dot it 2007-04-23 14:59 --- Created an attachment (id=1733) --> (http://sourceware.org/bugzilla/attachment.cgi?id=1733&action=view) Fixes the problem above -- http://sourceware.org/bugzilla/show_bug.cgi?id=4412 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4412] windres is not 64bit are
-- What|Removed |Added CC||sherpya at netfarm dot it http://sourceware.org/bugzilla/show_bug.cgi?id=4412 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Error: can't resolve `.hcu.uncommon_code' {.hcu.uncommon_code section} - `.LFB17' {.text section}
Hi Jim,
Thanks for the response. Indeed, there's no section change that would
position label LFE17 in the .text section, where main is.
On Sat, 2007-04-21 at 10:35 -0700, Jim Wilson wrote:
> It looks like you are trying to do some complicated (and probably
> fragile) section switching stuff in a C function using gcc extended
> asms, and that there is an unbalanced section switch somewhere. Or
> maybe gcc optimization is breaking your code.
I wonder if this is a result of dead-code elimination by gcc, and if
there's a way to change this behavior. I've traced this down to the
following C code:
==
hcu_wrapped_main_0_before:
/* more stuff */
if (var == 1)
{
hcu_save_frame_of_main_v1 ((void *) (&hcu_stack_local_main_var),
&hcu_stack_local_main_var.
hcu_stack_frame_fields, 2, 7);
return;
hcu_wrapped_main_2_after:;
}
goto hcu_wrapped_main_0_before;
__asm__ __volatile__ ("hcu_uncommon_section_"
"main_v1_hcu_wrapped_main_0_call_must_not"
":\n\t");;
__asm__ __volatile__ ("jmp 1f\n\t" ".text\n\t" "1:\n");;
==
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. 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.
The only other alternative I see is to acquire the value of the
hcu_wrapped_main_0_before label using the && operator
(http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html) and write
something like:
__asm__ __volatile__ ("jmp %0\n\t"
"hcu_uncommon_section_"
"main_v1_hcu_wrapped_main_0_call_must_not"
":\n\t"
: /* no output */
: "g" (&&hcu_wrapped_main_0_before) );;
__asm__ __volatile__ ("jmp 1f\n\t" ".text\n\t" "1:\n");;
It's not an ideal solution for two reasons. Labels as values are not ISO
C. And these assembly statements are produced using macros that could be
conditionally defined to something a lot more simpler (just a "}") when
cache locality is not an issue. I was hoping to keep those macros.
Thanks again,
Kristis
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Error: can't resolve `.hcu.uncommon_code' {.hcu.uncommon_code section} - `.LFB17' {.text section}
Kristis Makris <[EMAIL PROTECTED]> writes: > Labels as values are not ISO C. Neither are asm statements. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Error: can't resolve `.hcu.uncommon_code' {.hcu.uncommon_code section} - `.LFB17' {.text section}
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 ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/4414] New: unrecognized option `-mc68020'
Ñonfigure binutils with option --enable-targets=all --enable-shared --program- prefix=all-target- --prefix=/usr/local/binutils During compilation "gcc" with options --enable-shared \ --enable-languages=c \ --verbose \ --program-prefix=m68k-coff- \ --with-as=/usr/local/binutils/bin/all-target-as --with-ld=/usr/local/binutils/bin/all-target-ld --target=m68k-coff \ Error: /usr/local/binutils/bin/all-target-as: unrecognized option `-mc68020' -- Summary: unrecognized option `-mc68020' Product: binutils Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: ivbx at mail dot ru CC: bug-binutils at gnu dot org GCC host triplet: i686 GCC target triplet: all http://sourceware.org/bugzilla/show_bug.cgi?id=4414 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/4414] unrecognized option `-mc68020'
--- Additional Comments From schwab at suse dot de 2007-04-23 23:36 --- The assembler can only be configured for a single target cpu (which defaults to host if not given). You need to configure binutils for the same primary target as the compiler. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4414 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
