[Bug binutils/2015] Segfault in setlocale() call makes programs unusable
--- Additional Comments From amodra at bigpond dot net dot au 2007-08-07 06:23 --- Fix available, and not a binutils bug. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=2015 --- 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 ld/2112] Binutils LD fails at line 6419 of elflink.c
--- Additional Comments From amodra at bigpond dot net dot au 2007-08-07 06:18 --- I'm reasonably confident this has been fixed, and this bug has been in "waiting" for a long time. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://sourceware.org/bugzilla/show_bug.cgi?id=2112 --- 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 ld/4538] add --all-init flag to force all static initializers to be loaded
--- Additional Comments From ian at airs dot com 2007-08-07 05:30 --- What advantage will --all-init bring you over --whole-archive? How would you define --all-init in terms of the linker? You are defining it in terms of C++. But different C++ implementations handle static constructors completely differently. You need to define what --all-init should do in linker terms. Quite aside from that, this is not a bug. I recommend that you define what the linker should do, write a patch, and send it to the mailing list to see what people think. Please don't keep reopening this bug. That is inappropriate behaviour. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://sourceware.org/bugzilla/show_bug.cgi?id=4538 --- 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 ld/4538] add --all-init flag to force all static initializers to be loaded
--- Additional Comments From cnmnzusoib at mailinator dot com 2007-08-07
05:17 ---
Apparently not. :-P
Now, disabling my bugzilla account -- that's *really* classy. Glad to know I'm
dealing with a
professional adult, not a hyperventilating dictator-for-life ("because I said
so, that's why! Respect my
authori-tay!")
So... would any of the *other* "Blanket Write Privs" types care to step in and
explain why adding an --
all-init flag would be such a terrible idea that it shouldn't be even
considered as a possible future
enhancement? (quick summary: --all-init is like --whole-archive, but just for
those units with static
initialization sections, so stuff like 'int register =
doFactoryRegistration("Foo");' actually gets
called reliably...)
If there's actually some rationale here, I'd be happy to move on. If Mr.
Modra's just abusing his power
to do a quick sweep of his plate under the carpet so he can look efficient at
closing bugs, I'm not so
happy.
--
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WONTFIX |
http://sourceware.org/bugzilla/show_bug.cgi?id=4538
--- 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 ld/4538] add --all-init flag to force all static initializers to be loaded
--- Additional Comments From amodra at bigpond dot net dot au 2007-08-07 04:25 --- This isn't a debating society. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://sourceware.org/bugzilla/show_bug.cgi?id=4538 --- 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 ld/4538] add --all-init flag to force all static initializers to be loaded
--- Additional Comments From ejt at andrew dot cmu dot edu 2007-08-07 03:37 --- Such a good, persuasive argument! You've raised many good points that I hadn't considered... OK then, lets call it an "enhancement", and I'll reword the summary for you. The fact that this issue keeps coming up (see referenced threads at the beginning of the thread) should tell you that this is an ongoing problem for users. I don't see why you refuse to even consider the option of fixing it. For heaven's sake, no one says *you* have to do it, just leave the report open as a known issue so people can track it and maybe someday someone *else* will be inspired to give it a shot. And for reference, here's the work around I've personally settled on in the mean time: I added a pre- linking step to my Makefile to scan for symbols named 'autoRegister*', and then pass '-u' flags for each of those symbols when doing the final link to make sure their initializers get pulled in, like so: @undef=`nm -g "project.a" | grep "autoRegister" | grep -v " *U" | cut -f 3 -d ' ' | sort -u | sed 's/^/-u /'`; \ $(CXX) -o $@ $$undef $(OBJS) $(libs) ; Of course, it'd sure be nice to have an "official" way to handle this that doesn't involve specially-named symbols or bash scripts wrapped around the linker... e.g. adding a --all-init flag, perhaps? -- What|Removed |Added Severity|normal |enhancement Status|RESOLVED|REOPENED Resolution|INVALID | Summary|static initialization |add --all-init flag to force |ignored in static archive |all static initializers to |(.a)|be loaded http://sourceware.org/bugzilla/show_bug.cgi?id=4538 --- 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 amodra at bigpond dot net dot au 2007-08-07 01:32 --- m68k-coff is no longer supported. You'll need to use an older binutils. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID 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 ld/4515] bad definition of start address in ldscripts for OMAGIC
--- Additional Comments From amodra at bigpond dot net dot au 2007-08-07 01:27 --- As Nick says, current x86-aout scripts have . = 0. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://sourceware.org/bugzilla/show_bug.cgi?id=4515 --- 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 ld/4538] static initialization ignored in static archive (.a)
--- Additional Comments From amodra at bigpond dot net dot au 2007-08-07 01:22 --- Not a bug. Please do not reopen. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=4538 --- 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 libc/4781] binutils 2.17.50.0.7 and later eats up memory when calling gnujava wizards in OpenOffice
--- Additional Comments From drow at sources dot redhat dot com 2007-08-06 19:38 --- Oh, I see. Without that unwinder patch, if the PC wasn't saved we'll end up with a segfault. Since this is coming through Java, I assume we're getting the unwinder re-invoked from the signal handler, and burning out the stack. I still don't get why the binutils patch made a difference, but this is clearly not a binutils bug. If you have a change, it would be nice to get the unwinder fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=4781 --- 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 libc/4781] binutils 2.17.50.0.7 and later eats up memory when calling gnujava wizards in OpenOffice
--- Additional Comments From jakub at redhat dot com 2007-08-06 18:59 --- I have posted an unwinder patch in the thread I referenced, see http://gcc.gnu.org/ml/gcc/2006-12/msg00312.html but that was without ChangeLog entry, I got no feedback and forgot about it (because in the meantime I have reverted Jan's glibc patch on fedora-branch and so didn't ever see it again). -- http://sourceware.org/bugzilla/show_bug.cgi?id=4781 --- 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 libc/4781] binutils 2.17.50.0.7 and later eats up memory when calling gnujava wizards in OpenOffice
--- Additional Comments From drow at sources dot redhat dot com 2007-08-06 18:52 --- HJ suggested this bug should be resolved before 2.18, but that was the day before the glibc patch was identified. Could someone explain to me, in small words, how Jakub's patch could "cause" this if it is not a binutils bug? Is it really a bug in the GCC unwinder that we are now triggering? I don't see anything fundamentally wrong with the glibc patch and I haven't seen any fixes for the unwinder either. -- What|Removed |Added CC||drow at sources dot redhat ||dot com http://sourceware.org/bugzilla/show_bug.cgi?id=4781 --- 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/4791] Update to latest gnustandards (Was: etc/standards.texi: @strong{Note...} produces a spurious cross-reference in Info)
--- Additional Comments From nightstrike at gmail dot com 2007-08-06 17:38
---
I changed the title to reflect that. What else must be done to upgrade to the
latest version?
--
What|Removed |Added
Summary|etc/standards.texi: |Update to latest
|@strong{Note...} produces a |gnustandards (Was:
|spurious cross-reference in |etc/standards.texi:
|Info|@strong{Note...} produces a
||spurious cross-reference in
||Info)
http://sourceware.org/bugzilla/show_bug.cgi?id=4791
--- 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: [incomplete patch] Get objdump to report exception tables for ARM/SH4 correctly
Hi Danny, 2. Cleanup in my_symbol_for_address. There's none now. Should there be? Yes. :-) Also it looks like my_symbol_for_address is going to quite slow for large symbol tables. You might want to consider ensuring that the symbol time is sorted by address and then performing some kind of binary search on it. (Or do you know that my_symbol_for_address will always be called with incrementally increasing addresses, in which case you could just cache the last returned value and start your search there). 3. Which macros should be used for the conditional compilation ? I've used #if defined(ARM_WINCE) || defined(SH4) in my code. This happens to work for me because our build chain defines ARM_WINCE, but I don't suppose this is right. The correct way to handle this is to add a new function pointer field to the bfd_coff_backend_data structure. Arrange for this field to be initialized by the various backends that need it (IA64, ARM, MIPS, SH) pointing at static functions defined in the appropriate target specific source file (pe-arm.c etc), and otherwise for it to be empty(*). Then in _bfd_XX_print_private_bfd_data_common test the field and call it if it is not empty. Cheers Nick (*) Or maybe to point at a default pdata display function which does not try to provide any target specific interpretation. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4791] etc/standards.texi: @strong{Note...} produces a spurious cross-reference in Info
--- Additional Comments From nickc at redhat dot com 2007-08-06 14:26
---
Subject: Re: etc/standards.texi: @strong{Note...} produces
a spurious cross-reference in Info
Hi,
> I have reviewed the current version of the standards.texi file. Should this
> bug
> report be the one that requests updating to the latest version of
> "gnustandards", or is that in the project plan for binutils somewhere?
This bug report is fine.
Cheers
Nick
--
http://sourceware.org/bugzilla/show_bug.cgi?id=4791
--- 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: [Bug binutils/4791] etc/standards.texi: @strong{Note...} produces a spurious cross-reference in Info
Hi, I have reviewed the current version of the standards.texi file. Should this bug report be the one that requests updating to the latest version of "gnustandards", or is that in the project plan for binutils somewhere? This bug report is fine. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[incomplete patch] Get objdump to report exception tables for ARM/SH4 correctly
[Retry to send this message without the attachment that probably blocked
the earlier attempt.]
I've attached a patch that'll get objdump to report exception tables
correctly for ARM and SH4 which, according to MSDN, have a different
format for storing the pdata segment.
Here's part of the output, used on a test executable :
dannypc: {642} tail ~/tmp/arm/test/exception/syntax.od
603c
The Function Table (interpreted .pdata section contents)
vma: BeginProlog Function FlagsException EH
Address Length Length 32b exc Handler Data
00014000 00011008 0002 000f 1 1 000110f8
(_eh_handler)
00014008 000110a4 0002 0015 1 1 00011058
(handler)
private flags = 820: [APCS-32] [floats passed in integer registers]
[absolute position] [interworking not supported]
dannypc: {643}
I have three uncertainties with this patch :
1. I've copied code from elsewhere in binutils. Just want to point to
the fact that I did this; I don't think this one is worth exporting as a
public API.
2. Cleanup in my_symbol_for_address. There's none now. Should there be?
3. Which macros should be used for the conditional compilation ? I've
used
#if defined(ARM_WINCE) || defined(SH4)
in my code. This happens to work for me because our build chain defines
ARM_WINCE, but I don't suppose this is right.
Attached are :
- a sample ChangeLog entry
- the patch in its current state
- a gzipped sample file on which this can be used to produce the output
as above. I've renamed it slightly, to avoid virus scanners.
Please advise on how to proceed.
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
2007-08-05 Danny Backx <[EMAIL PROTECTED]>
* bfd/peXXigen.c (pe_print_pdata) : Add code to support ARM and SH4
compressed .pdata segments as described on MSDN.
* bfd/peXXigen.c (slurp_symtab, my_symbol_for_address) : New private
functions, copied from/based on other binutils source files.
Index: bfd/peXXigen.c
===
--- bfd/peXXigen.c (revision 1020)
+++ bfd/peXXigen.c (working copy)
@@ -1561,16 +1561,63 @@
return TRUE;
}
+static int symcount=0;
+static asymbol **
+slurp_symtab (bfd *abfd)
+{
+ asymbol **sy = NULL;
+ long storage;
+
+ if (!(bfd_get_file_flags (abfd) & HAS_SYMS))
+{
+ symcount = 0;
+ return NULL;
+}
+
+ storage = bfd_get_symtab_upper_bound (abfd);
+ if (storage < 0)
+return NULL;
+ if (storage)
+sy = bfd_malloc (storage);
+
+ symcount = bfd_canonicalize_symtab (abfd, sy);
+ if (symcount < 0)
+return NULL;
+ return sy;
+}
+
+static const char *
+my_symbol_for_address(bfd *abfd, bfd_vma func)
+{
+ static asymbol **syms = 0;
+ int i;
+
+ if (syms == 0)
+ syms = slurp_symtab (abfd);
+ for (i=0; isection->vma + syms[i]->value == func)
+ return syms[i]->name;
+ }
+ return NULL;
+}
+
/* This really is architecture dependent. On IA-64, a .pdata entry
consists of three dwords containing relative virtual addresses that
specify the start and end address of the code range the entry
- covers and the address of the corresponding unwind info data. */
+ covers and the address of the corresponding unwind info data.
+ On ARM and SH-4, a compressed PDATA structure is used :
+ _IMAGE_CE_RUNTIME_FUNCTION_ENTRY, whereas MIPS is documented to use
+ _IMAGE_ALPHA_RUNTIME_FUNCTION_ENTRY.
+ See http://msdn2.microsoft.com/en-us/library/ms253988(VS.80).aspx .
+ */
static bfd_boolean
pe_print_pdata (bfd * abfd, void * vfile)
{
#if defined(COFF_WITH_pep) && !defined(COFF_WITH_pex64)
# define PDATA_ROW_SIZE (3 * 8)
+#elif defined(ARM_WINCE) || defined(SH4)
+# define PDATA_ROW_SIZE (2 * 4)
#else
# define PDATA_ROW_SIZE (5 * 4)
#endif
@@ -1598,6 +1645,10 @@
#if defined(COFF_WITH_pep) && !defined(COFF_WITH_pex64)
fprintf (file,
_(" vma:\t\t\tBegin AddressEnd Address Unwind Info\n"));
+#elif defined(ARM_WINCE) || defined(SH4)
+ fprintf (file, _("\
+ vma:\t\tBeginProlog Function FlagsException EH\n\
+ \t\tAddress Length Length 32b exc Handler Data\n"));
#else
fprintf (file, _("\
vma:\t\tBeginEnd EH EH PrologEnd Exception\n\
@@ -1620,16 +1671,75 @@
for (i = start; i < stop; i += onaline)
{
bfd_vma begin_addr;
+#if defined(ARM_WINCE) || defined(SH4)
+ bfd_vma other_data;
+ bfd_vma prolog_length, function_length;
+ int flag32bit, exception_flag;
+ bfd_byte *tdata = 0;
+ asection *tsection;
+#else
bfd_vma end_addr;
bfd_vma eh_handler;
bfd_vma eh_data;
bfd_vma prolog_end_addr;
int em_data;
+#endif
if (i + PDATA_ROW_SIZE > stop)
break;
+#if defined(ARM_WINCE) || defined(SH4)
begin_addr = GET_PDATA_ENTRY (abfd, data + i );
+ other_data
