[Bug binutils/10773] New: Malformed archive created when adding several files at once
Multiple invocations with one file per invocation of ar rv successfully create an archive, but invoking ar rv with several files at once creates a "Malformed archive" according to ar t. I can provide a reproducible test case upon request---I don't see a place to add attachments in Bugzilla, or I would have added it already. $ ar V GNU ar (GNU Binutils; openSUSE 11.1) 2.19 $ uname -a Linux mchn144c 2.6.27.29-0.1-default #1 SMP 2009-08-15 17:53:59 +0200 x86_64 x86 _64 x86_64 GNU/Linux -- Summary: Malformed archive created when adding several files at once Product: binutils Version: 2.19 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: konrad dot schwarz at siemens dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10773 --- 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/10774] New: Bogus documentation
Chapter 3.5.4, "Source Code Reference", of the ld Manual is so inaccurate and inconsistent in its use of vocabulary with the rest of the manual that it should be replaced. A detailed critique is below; I suggest the following replacement: 3.5.4 Accessing Symbols defined in Linker Scripts in Source Code The value of a symbol is its address. Thus, to access a symbol's value, declare it an external variable and use its address. Note that in most cases, symbols defined by linker scripts do *not* have any associated storage assigned to them, so it is typically an error to read from or write to such an external variable! For example, the Unix System V documentation traditionally uses the following C declarations for the end of the text segment, the end of the data segment, and the end of the BSS segment, which System V marks with the symbols ``etext'', ``edata'', and ``end'': extern etext; extern edata; extern end; Note that these declarations implicitly use a type of ``int''. One can choose the type most appropriate to the application, because type checking is not done during link editing. E.g., declaring such symbols as incomplete arrays of const char enables the C compiler to diagnose writes, reads (without array dereference) and use of the sizeof operator as errors: extern char const end []; Finally, note that some systems perform a transformation between variable names as used in a high-level language and symbol names as seen by the linker. The transformation is part of the ABI. E.g., a.out and COFF(?)-based systems prepend an underscore to variable names to arrive at the symbol name---this is done to create separate name spaces for high-level language modules and assembly language modules. Symbol names must take this transformation into account: e.g., the above symbols would be named ``_etext'', ``_edata'', and ``_end'' on such systems. In C++, the ``extern "C"'' modifier can be used to suppress the additional "mangling" of variable names done by that language. CRITIQUE OF CURRENT TEXT File: ld.info, Node: Source Code Reference, Prev: PROVIDE_HIDDEN, Up: Assign\ ments 3.5.4 Source Code Reference --- Accessing a linker script defined variable from source code is not >>symbol intuitive. In particular a linker script symbol is not equivalent to a variable declaration in a high level language, it is instead a symbol that does not have a value. >> ??? It has a value, it just might not have storage >> associated with it. This node's parent is titled "Assigning values to >> Symbols"! Before going further, it is important to note that compilers often transform names in the source code into different names when they are stored in the symbol table. For example, Fortran compilers commonly >> That mangling is defined by the ABI should be mentioned prepend or append an underscore, and C++ performs extensive `name mangling'. Therefore there might be a discrepancy between the name of a variable as it is used in source code and the name of the same variable as it is defined in a linker script. For example in C a linker script variable might be referred to as: extern int foo; But in the linker script it might be defined as: _foo = 1000; In the remaining examples however it is assumed that no name transformation has taken place. When a symbol is declared in a high level language such as C, two things happen. The first is that the compiler reserves enough space in the program's memory to hold the _value_ of the symbol. The second is >> data of the variable that the compiler creates an entry in the program's symbol table which >> technically, for gcc, the assembler >>object file's holds the symbol's _address_. ie the symbol table contains the address of the block of memory holding the symbol's value. So for example the following C declaration, at file scope: int foo = 1000; creates a entry called `foo' in the symbol table. This entry holds the address of an `int' sized block of memory where the number 1000 is initially stored. When a program references a symbol the compiler generates code that first accesses the symbol table to find the address of the symbol's >> Utter nonsense! memory block and then code to read the value from that memory block. So: foo = 1; looks up the symbol `foo' in the symbol table, gets the address associated with this symbol and then writes the value 1 into that address. Whereas: int * a = & foo; looks up the symbol `foo' in the symbol table, gets it address and then copies this address into the block of memory associated with the variable `a'. Linker scripts symbol declarations, by contrast, create an entry in the symbol table but do not assign any memory to them. Thus
[Bug binutils/969] objdump: wrong Coldfire disassembly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2009-10-14 11:30 --- Subject: Bug 969 CVSROOT:/cvs/src Module name:src Changes by: amo...@sourceware.org 2009-10-14 11:30:21 Modified files: opcodes: ChangeLog m68k-opc.c Log message: PR 969 * m68k-opc.c (m68k_opcodes): Correct mask for macl and msacl. Patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/ChangeLog.diff?cvsroot=src&r1=1.1473&r2=1.1474 http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/opcodes/m68k-opc.c.diff?cvsroot=src&r1=1.31&r2=1.32 -- http://sourceware.org/bugzilla/show_bug.cgi?id=969 --- 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/969] objdump: wrong Coldfire disassembly
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-14 11:32 --- Patch applied. Apologies for the horrendous delay. Ben, how many other bugs are you sitting on?? -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=969 --- 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/970] objcopy COFF -> ELF relocation translations forgets '-4' bias
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-14 11:35 --- Closing since I doubt any active developer will work on this. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://sourceware.org/bugzilla/show_bug.cgi?id=970 --- 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/2613] testcase for binutils:ld on alpha fails.
-- What|Removed |Added Status|ASSIGNED|NEW http://sourceware.org/bugzilla/show_bug.cgi?id=2613 --- 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/5136] Error message "rel too far BFD_RELOC_8" used with BFD_RELOC_16
-- What|Removed |Added Status|ASSIGNED|NEW http://sourceware.org/bugzilla/show_bug.cgi?id=5136 --- 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/10775] New: x86 64 documentation addenda
The following information is lacking from the GAS manual: In node (as.info)i386-Mnemonics, add at the end of 9.13.4, In 64-bit mode, `movabs' is the form of the mov instruction which loads a 64-bit literal into a register. The AT&T/Unixware assembler is documented at http://docs.sun.com/app/docs/doc/802-1948?l=en&q=assembler+manual and http://docs.sun.com/app/docs/doc/817-5477?l=en. In node (as.info)i386-Regs, before "* the 8 debug registers:" add * The processor control register `%cr8'. At the end of that node, add The 80386 flags register is not supported as a distinct register. Instead, the instructions `PUSH [ER]?FLAGS' and `POP [EA]?FLAGS' are encoded as `pushf[wlq]' and `popf[wlq]'. After node (as.info)i386-16bit, add a new section: 9.13.13 Writing 64-bit Code --- The `.code64' directive causes the assembler to emit AMD64 ``long mode'' (64-bit) code. As mentioned above, the `.code32' directive switches to 32-bit code. Which mode the assembler is in originally depends on the --32 and --64 options. -- Summary: x86 64 documentation addenda Product: binutils Version: 2.19 Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: konrad dot schwarz at siemens dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10775 --- 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/5487] linking with dllwrap causes crash
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-14 11:45 --- Closing as reporter says bug in migw runtime -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=5487 --- 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/6906] TLS relocs prevent changing r19 to r27 when doing static link with PIC code on PA
-- What|Removed |Added Status|ASSIGNED|NEW http://sourceware.org/bugzilla/show_bug.cgi?id=6906 --- 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 admin/10767] opcodes/i386-dis.c exceeds 256 levels of nested macros
-- What|Removed |Added Status|ASSIGNED|NEW http://sourceware.org/bugzilla/show_bug.cgi?id=10767 --- 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/3990] [PATCH] IA64 gas DV: reports spurious WAW hazards
-- What|Removed |Added Status|ASSIGNED|NEW http://sourceware.org/bugzilla/show_bug.cgi?id=3990 --- 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/1038] resolution of weak symbol not left for the linker if value is already known
-- What|Removed |Added Status|ASSIGNED|NEW http://sourceware.org/bugzilla/show_bug.cgi?id=1038 --- 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/873] Incorrect generation of relocs for .byte , .2byte and .3byte directives.
-- What|Removed |Added AssignedTo|ramana dot radhakrishnan at |unassigned at sources dot |codito dot com |redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=873 --- 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/10768] dlltool: selecting machine arch when creating .lib from .def file failed with unclear error message
--- Additional Comments From yann at droneaud dot fr 2009-10-14 12:21 --- Using gdb help find the problem: when another machine architecture is selected, the bfd target is not the one per default. And the selected bfd is not part of the build. So there's no bug, but the error message is unclear. -- What|Removed |Added Summary|dlltool: can't specify |dlltool: selecting machine |machine arch when creating |arch when creating .lib from |.lib from .def file |.def file failed with ||unclear error message http://sourceware.org/bugzilla/show_bug.cgi?id=10768 --- 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/10768] dlltool: selecting machine arch when creating .lib from .def file failed with unclear error message
--- Additional Comments From yann at droneaud dot fr 2009-10-14 12:29 --- Created an attachment (id=4278) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4278&action=view) dlltool: Improve error reporting regarding BFD open operations Here's a patch which help to diagnose problem regarding BFD open calls. Patch against CVS HEAD. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10768 --- 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/969] objdump: wrong Coldfire disassembly
--- Additional Comments From tom at hukatronic dot cz 2009-10-14 12:31 --- Thanks for applying the patch. I almost forget that I wrote it a four years ago. :-) -- http://sourceware.org/bugzilla/show_bug.cgi?id=969 --- 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/10777] New: Macro processing altercation
The state of macro processing in gas is rotten. I say this after spending an exorbitant amount of time in getting it to work on problems that other assemblers, such as from ARM, Tasking, Fujitsu have no problems with. (This is not helped by the fact that GAS's listing facility is flaky, but that is a different matter). For example, consider the task of using a symbol name that is computed, for example, setting the symbols .Lvector_used_0, .Lvector_used_1, ... .Lvector_used_255 to zero. The solution I have come up with after considerable experimentation is: /* concat required because in gas, .altmacro % expansion only works at the start of a word */ .macro concat s1, s2, s3, s4, s5 .noaltmacro \s1\s2\s3\s4\s5 .endm .Li = 256 .rept .Li - 0 .Li = .Li - 1 .altmacro concat .Lvector_used_, %.Li, < = 0> .endr ``Immediate'' expansion of a symbol is possible only in `.altmacro' mode, using the `%' operator. On the other hand, `.altmacro' mode uses `<' to delimit strings, which conflicts with its usual meaning of ``shift left''. So it is not a good idea to switch to `.altmacro' mode globally; instead it should be done only were necessary. Hence the call to `.altmacro' in the loop and the call to `.noaltmacro' in the concat macro. Even in `.altmacro' mode, `%' expansion is only recognized at the beginning of a word. Thus, the expression .Lvector_used_%.Li (which corresponds to vector_used [i] in a C-like language) must be written as separate words. Hence the `concat' macro, which allows a separate round of evaluation. The call to `concat' represents the line .Lvector_used\(.Li) = 0 if `\(_expr_)' meant to evaluate `_expr_' immediately. And in fact, I would like to recommend this as a way forward. If `\()' were extended in this way, use of GAS would be much more straightforward, as demonstrated by this example. The parenthesis serve to clearly delimit the expression; thus, it can be embedded into the middle of a word. As another thing, clarification of the way macro arguments are parsed would be in order. It seems from the example in (as.info)Macro that arguments can be enclosed in double quotes and that they are stripped before expansion, but this is not stated anywhere. I realize that implementing `\(expr)' is not entirely trivial, so I would like to request built-in support for M4 as a preprocessor, just like the Unix System V assembler. In particular, the System V assembler has a `-m' option which invokes m4 on its source and assembles the result. This option is important for easy integration with `make' default rules: e.g., in GNU make, adding `-Wa,-m' to ASFLAGS would enable using just the default rule catalog to compile such sources; otherwise, a separate rule needs to be created and a naming scheme (such as a suffix) be reserved for these files. The benefit of M4 is that it is well documented, extremely capable, and offers a clear separation between the preprocessing and assembly phases of processing, similar to C. It is also possible to view the output of preprocessing for debugging, whereas various errors cause GAS to omit the listing file or to write it out incompletely. In such a case, correcting parse errors is extremely tedious -- I had to resort to adding deliberate syntax errors to zero in on the locations of actual errors. In contrast, the use of link-time symbols as preprocessing variables in GAS requires them to be marked as temporary (prefixed with .L in ELF files), which is detrimental to legibility, and the GAS 1-pass approach makes it hard to figure out what value will actually be used. Note that for example the IBM mainframe assembler similarly differentiates between variables used by the macro processor and symbols. The only drawback I can see of such a ``phased'' approach is that symbol values cannot direct preprocessing. As the IBM example shows, this is a viable trade off. -- Summary: Macro processing altercation Product: binutils Version: 2.19 Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: konrad dot schwarz at siemens dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10777 --- 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/1040] Many packages fail to compile with binutils 2.16.1 because of ldscripts screwup
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-14 14:12 --- . -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=1040 --- 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/1219] binutils fail to recognize executables and shared libraries generated by Sun Studio 10 CC
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-14 14:28 --- My guess is that this has been fixed in 2.20. Closing anyway as no feedback in 4 years -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=1219 --- 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/1491] FAIL: macros dot
-- What|Removed |Added Status|WAITING |NEW Last reconfirmed|-00-00 00:00:00 |2009-10-14 14:30:44 date|| http://sourceware.org/bugzilla/show_bug.cgi?id=1491 --- 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/10778] New: wince target should use pei-arm-wince-little target
When asking for arm-wince target, binutils are built to use pe-arm-wince-little format. But it seems that Visual Studio is generating executable / .lib with format pei-arm-wince-little. In particular, dlltool and as have no option to choose between pe-arm-wince-little and pei-arm-wince-little -- Summary: wince target should use pei-arm-wince-little target Product: binutils Version: 2.19 Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: yann at droneaud dot fr CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=10778 --- 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/10778] wince target should use pei-arm-wince-little target
--- Additional Comments From yann at droneaud dot fr 2009-10-14 14:42 --- Created an attachment (id=4279) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4279&action=view) Try to enable pei-arm-wince as machine in dlltool Here is a patch which try to enable pei-arm-wince-little as BFD target for dlltool. Generating .lib file doesn't work as expected: produce a mix of pe-arm-wince-little and pei-arm-wince-little with ambigous warning from objdump -- http://sourceware.org/bugzilla/show_bug.cgi?id=10778 --- 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 admin/10767] opcodes/i386-dis.c exceeds 256 levels of nested macros
--- Additional Comments From hjl dot tools at gmail dot com 2009-10-14 14:56 --- (In reply to comment #2) > Oh, it was not meant as a fix. Just as an information. You can try enum. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10767 --- 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/1491] FAIL: macros dot
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2009-10-14 16:21 --- Subject: Re: FAIL: macros dot On Wed, 14 Oct 2009, amodra at bigpond dot net dot au wrote: === gas tests === Schedule of variations: unix Running target unix Using /opt/gnu/share/dejagnu/baseboards/unix.exp as board description file for target. Using /opt/gnu/share/dejagnu/config/unix.exp as generic interface file for target. Using /xxx/gnu/binutils/src/gas/testsuite/config/default.exp as tool-and-target-specific interface file. Running /xxx/gnu/binutils/src/gas/testsuite/gas/all/gas.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/alpha/alpha.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/arc/arc.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/arc/warn.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/arm/arm.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/bfin/bfin.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/bfin/error.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/cfi/cfi.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/cr16/cr16.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/cr16/pic.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/cris/cris.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/crx/allinsn.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/d10v/d10v.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/d30v/d30.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/dlx/alltests.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/elf/elf.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/fr30/allinsn.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/fr30/fr30.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/frv/allinsn.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/h8300-coff.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/h8300-elf.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/h8300.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t01_mov.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t02_mova.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t03_add.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t04_sub.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t05_cmp.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t06_ari2.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t07_ari3.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t08_or.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t09_xor.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t10_and.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t11_logs.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t12_bit.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/h8300/t13_otr.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/hppa/basic/basic.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/hppa/parse/parse.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/hppa/reloc/reloc.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/hppa/unsorted/unsorted.exp ... XPASS: Use $global$ in file which defines it Running /xxx/gnu/binutils/src/gas/testsuite/gas/i386/i386.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/i860/i860.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/ia64/ia64.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/ieee-fp/x930509a.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/iq2000/allinsn.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/iq2000/load-hazards.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/iq2000/odd-ldw.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/iq2000/odd-sdw.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/iq2000/yield.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/lm32/all.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/lns/lns.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m32r/allinsn.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m32r/error.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m32r/m32r.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m32r/m32r2.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m32r/m32rx.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m32r/pic.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m32r/rel32.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m68hc11/m68hc11.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m68k-coff/gas.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/m68k/all.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/macros/macros.exp ... FAIL: macros dot Running /xxx/gnu/binutils/src/gas/testsuite/gas/maxq10/maxq10.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/maxq20/maxq20.exp ... Running /xxx/gnu/binutils/src/gas/testsuite/gas/mcore/a
[Bug gold/10238] Gold linker does not resolve symbols using indirect dependencies
--- Additional Comments From roland at gnu dot org 2009-10-14 22:18 --- Please make gold accept and ignore the --no-add-needed switch so there is a single command line that has the same semantics for both ld implementations. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10238 --- 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/1491] FAIL: macros dot
--- Additional Comments From amodra at bigpond dot net dot au 2009-10-15 01:19 --- Looking into it. Caused by LABELS_WITHOUT_COLONS -- What|Removed |Added AssignedTo|unassigned at sources dot |amodra at bigpond dot net |redhat dot com |dot au Status|NEW |ASSIGNED Last reconfirmed|2009-10-14 14:30:44 |2009-10-15 01:19:12 date|| http://sourceware.org/bugzilla/show_bug.cgi?id=1491 --- 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
