Re: strip doesn't maintain /LARGEADDRESSAWARE flag
Hi Jan, 1. Please could you create a bugzilla issue to track this bug. 2. Please could you supply a *small* test binary with the LARGEADDRESSAWARE flag set. Many of us, including myself, do not have Microsoft's Visual Stdio installed and so we are unable to create such a binary ourselves. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/716] strip doesn't maintain /LARGEADDRESSAWARE flag (mingw build, Windows 2000)
Hi Jan,
Even more KISS-like:
if (pe_data (obfd) != NULL && pe_data (ibfd) != NULL
&& (pe_data (obfd)->real_flags & 0x20))
pe_data (obfd)->real_flags |= 0x20;
Except of course that you want to check for the presence of the flag in
the *input* bfd and then copy it to the output bfd... So I have checked
in this version of the patch:
bfd/ChangeLog
PR binutils/716
* peicode.h (pe_bfd_copy_private_bfd_data): Copy the large address
aware flag from the input bfd to the output bfd.
Index: bfd/peicode.h
===
RCS file: /cvs/src/src/bfd/peicode.h,v
retrieving revision 1.42
diff -c -3 -p -r1.42 peicode.h
*** bfd/peicode.h 31 Jan 2005 23:13:29 - 1.42
--- bfd/peicode.h 14 Feb 2005 11:17:43 -
*** static bfd_boolean
*** 384,389
--- 384,397
pe_bfd_copy_private_bfd_data (ibfd, obfd)
bfd *ibfd, *obfd;
{
+ /* PR binutils/716: Copy the large address aware flag.
+ XXX: Should we be copying other flags or other fields in the
pe_data()
+ structure ? */
+ if (pe_data (obfd) != NULL
+ && pe_data (ibfd) != NULL
+ && pe_data (ibfd)->real_flags & IMAGE_FILE_LARGE_ADDRESS_AWARE)
+ pe_data (obfd)->real_flags |= IMAGE_FILE_LARGE_ADDRESS_AWARE;
+
if (!_bfd_XX_bfd_copy_private_bfd_data_common (ibfd, obfd))
return FALSE;
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: GNU ld to support incremental linking?
Hi Brian, Anyone have any information about what work may have been done on a true incremental link mode? Sorry - as far as I know noone has done any work on this. Anyone have any comments, wish lists, or warnings about how to go about potentially implementing it? There are probably several research papers out there if you care to search the academic world, but other than that the only documentation that I know of are the manuals for the commercial linkers that implement it. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/750] Addr2line reports function name that is inconsistent with file/line info for C++
Hi Fred, Proposed patch to fix the reported problem This looks fine. Please apply. If you can think of a way to create a test case for it, that would be good too. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/754] New: --image-base / --enable-auto-image-base silently disregarded if .def used
Hi, If a .def file is used to link a DLL, the --image-base and --enable-auto-image-base options are silently disregarded, even if the .def file is missing a BASE directive. The correct behavior should probably be that --image-base should override the .def file, and --enable-auto-image-base should override if a BASE directive is absent (but not otherwise). Please could you try the current binutils sources from the mainline of the CVS repository. It may well be that this bug has already been fixed. If not, please could you provide a small test case that reproduces the problem. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/753] New: ld 2.13.90 from mingw 3.3.1 cores on malformatted .def file
Hi, when linking a DLL with a .DEF file, if the BASE directive in the .DEF file is not of the form "BASE=0x1c00" but e.g. "BASE 0x1c00" or some other malformatting, ld crashes with a memory access violation. Please could you try using the current binutils sources from the mainline of the CVS repository. It may well be that the bug has already been fixed. If not, then please could you post a small test case that will reproduce the problem. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/760] New: ar (version 050223 20050223) segfaults at line 4422
Hi Eric, GCC 3.4.3 was used to build binutils and the object files below. This problem is reproducable in binutils 040922. Does the bug happen if you use the current mainline sources from the binutils CVS repository ? I will check to see if this happens on AIX 5.2 and 5.3. Does it ? The object files were built with g++ -g -O2. I have the object files for debugging if you need them. Well really we would prefer a small self contained test case, but if you cannot manage that then if you could put the files up for ftp/http somewhere that would be helpful. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: xregex2.h:549 "Unexpected text integer"
Hi Clint, I'm getting the following error trying to install binutils-2.15 on z/os 1.4: ERROR CCN3275 ./../include/xregex2.h:549 Unexpected text integer constant enco untered. WARNING CCN3213 ./config.h:368 Macro name inline cannot be redefined. WARNING CCN3343 ./regex.c:4265 Redeclaration of byte_store_op1 differs from pre vious declaration on line 1875 of "./regex.c". WARNING CCN3343 ./regex.c:4279 Redeclaration of byte_store_op2 differs from pre Actually these appear to be problems with libiberty which is actually part of the gcc distribution although it is used by binutils. Have you tried using the current binutils sources in the CVS repository ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: bug report
Hi Bob, I have received this bug using GNAT GDB 3.15p. Is there anything I can do to get more information on what's failing? (ie environment variable) BFD: BFD internal error, aborting at coffcode.h line 749 in styp_to_sec_flags BFD: Please report this bug. You can run the program inside GDB. You should then be able to backtrack from the abort to find out what is happening. Also if you are using an older version of binutils then you might try upgrading to the latest release (2.15) or even the mainline sources in the CVS repository. If neither of these things helps then you can submit a bug report for us to investigate. There is a bugzilla system set up at: http://sources.redhat.com/bugzilla/ Or you could email a report to this list. (Please do try to include as much helpful information as possible, and if at all practical a *small* testcase that reproduces the problem). Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/795] UCN problems exposed by GCC tests: gcc.dg/ucnid-2.c, 3, 4 and 6.
Hi Hans-Peter, In response to comment #1, I would expect GAS to assemble it because it's generated by GCC (presumed correct). My current theory is that it must be a gcc bug. But then I could just be passing the buck... Since you have a mmix-knuth-mmixware toolchain available, I suggest looking at the generated assembly from gcc.dg/ucnid-2.c. You should see this symbol. Hmm, well what I see is: [...] LC:0 IS @ BYTE #e3,#82,#b2,#0 [...] (with no embedded 0x80 or 0xc3 characters) I don't know why you had success assembling the test-cases on your system. I'm on FC2. I'm on RedHat Enterprise Linux 3 but I am using a gcc toolchain built from today's sources in the FSF GCC repository (and today's binutils). Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: 'objcopy --remove-leading-char' removes all exports from library
Hi Benjamin, ObjCopy version 2.14.90 objcopy --remove-leading-char libmqrt.a libmqrt2.a Now if I do a dumpbin /exports libmqrt2.a , all the exports are gone! Could you try repeating this test using the latest sources in the binutils CVS repository - I think that the problem might be fixed there. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
Hi Vladimir, After patch http://sourceware.org/ml/binutils-cvs/2005-03/msg00191.html binutils build broken at FreeBSD 5.3 Build terminate with message: In file included from /usr/home/wanderer/pkg/build/binutils/src/src/binutils/size.c:34: /usr/home/wanderer/pkg/build/binutils/src/src/binutils/../include/getopt.h:116: warning: function declaration isn't a prototype I see this warning long time (>2 years) already when i build binutils at FreeBSD. Using --disable-werror help build binutils. Sorry - we have decided to enable -Werror by default on the gcc command line when building binutils. If you can tell us how to reliably determine a prototype for the getopt() function under FreeBSD then we can fix the getopt.h header file. Otherwise you will have to continue building binutils with --disable-werror on the configure command line. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
Hi Vladimirm, Attached patch fix warning. Thanks. I don't known is proposed patch correct. But I check FreeBSD CVS and found that starting from 1994 FreeBSD have getopt prototype same as in binutils getopt.h. Well that should be long enough. I think that the patch is OK, but there are two problems: 1. The patch should be submitted to the gcc project, since they control the getopt.h header file. 2. You need to include a ChangeLog entry with your patch. Also, I am not sure if the FreeBSD system uses the GNU C library. I guess that it probably does, but if not then you ought to update the comment describing when the full getopt() prototype is used. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
Hi Vladimir, ian> Sorry, this patch is not OK. It will just lead us down the path of ian> increasing the #ifdef over and over again. The question here is why ian> HAVE_DECL_GETOPT is not defined. ian> ian> Looking at gcc, I would say that the binutils configure.in file should ian> do the equivalent of gcc_AC_CHECK_DECLS(getopt) to get ian> HAVE_DECL_GETOPT defined appropriately. I am not gury in configure magic and then I can't provide acceptable patch. *sigh* I hate configure file hacking. Please could you try the patch below which *might* work. I have not tested it very much. You ought to regenerate the configure files after applying this patch but in case this is a problem for you I am attaching a compressed diff for them as well. Cheers Nick Index: binutils/configure.in === RCS file: /cvs/src/src/binutils/configure.in,v retrieving revision 1.48 diff -c -3 -p -r1.48 configure.in *** binutils/configure.in 16 Mar 2005 17:18:15 - 1.48 --- binutils/configure.in 24 Mar 2005 21:04:39 - *** if test $bu_cv_decl_time_t_types_h = yes *** 180,185 --- 180,195 [Is the type time_t defined in ?]) fi + AC_MSG_CHECKING(for an known getopt prototype in unistd.h) + AC_CACHE_VAL(bu_cv_decl_getopt_unistd_h, + [AC_TRY_COMPILE([#include ], [extern int getopt (int, char *const*, const char *);], + bu_cv_decl_getopt_unistd_h=yes, bu_cv_decl_getopt_unistd_h=no)]) + AC_MSG_RESULT($bu_cv_decl_getopt_unistd_h) + if test $bu_cv_decl_getopt_unistd_h = yes; then + AC_DEFINE([HAVE_DECL_GETOPT], 1, + [Is the prototype for getopt in in the expected format?]) + fi + # Under Next 3.2 apparently does not define struct utimbuf # by default. AC_MSG_CHECKING([for utime.h]) Index: binutils/config.in === RCS file: /cvs/src/src/binutils/config.in,v retrieving revision 1.16 diff -c -3 -p -r1.16 config.in *** binutils/config.in 13 Oct 2004 14:33:50 - 1.16 --- binutils/config.in 24 Mar 2005 21:04:39 - *** *** 178,183 --- 178,186 /* Is the type time_t defined in ? */ #undef HAVE_TIME_T_IN_TYPES_H + /* Is the prototype for getopt in in the expected format? */ + #undef HAVE_DECL_GETOPT + /* Does define struct utimbuf? */ #undef HAVE_GOOD_UTIME_H binutils.config.patch.supplimental.bz2 Description: BZip2 compressed data ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
Hi Vladimir, Results of testting: And then configure part work fine at FreeBSD but binutils/config.h not #included in addr2line.c Hmm, but it does #include "bucomm.h" which then #include's "config.h". It turns out however that it incldues it too late (ie after "bfd.h"). So please try the attached patch (in addition to my previous patch). Cheers Nick Index: binutils/addr2line.c === RCS file: /cvs/src/src/binutils/addr2line.c,v retrieving revision 1.21 diff -c -3 -p -r1.21 addr2line.c *** binutils/addr2line.c15 Jun 2004 01:19:13 - 1.21 --- binutils/addr2line.c29 Mar 2005 15:33:56 - *** *** 29,34 --- 29,35 both forms write results to stdout, the second form reads addresses to be converted from stdin. */ + #include "config.h" #include #include "bfd.h" ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Unix "time" returns 43.833s. "gprof" returns 438 seconds.
Hi Jason, Unix "time" returns 43.833s. gprof returns 438 seconds. Either I'm going crazy or gprof is reporting a 10x increase? What could be causing this? A bug of some kind. Presumably in gprof. user0m43.646s Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 87.46381.78 381.78 256 1.49 1.49 readMB 12.95438.3256.53 256 0.22 0.22 writeMB Suppose that gprof had the wrong period for the sample. Suppose for example that each sample counted as 0.06 seconds. Then we can deduce that the actual cumulative time in seconds would be: 438.32 * 6 = 2629.92 seconds or 2629.92 / 60 = 43.83 minutes Which is pretty much what you are expecting yes ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/805] New: linking error: cannot handle R_MEM_INDIRECT reloc when using symbolsrec output
Hi dorchen1611, On creating a .lx File for hms-8300 microprocessor (Lego robot) following linker error occurs: cannot handle R_MEM_INDIRECT reloc when using symbolsrec output. Please could you supply a *small* self-contained test case that reproduces this problems and instructions on how to run the test case ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Fix typo in dwarf2.c and remove some dead code
Hi Fred, 2005-03-24 Fred Fish <[EMAIL PROTECTED]> * dwarf2.c (struct comp_unit): Fix typo. (scan_unit_for_functions): Remove unused local variable "name" and dead code that set it. Approved - please apply. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Binutils build broken at FreeBSD 5.3 after -Werror enabling
Hi Vladimir, addr2line.c compile with addition patch Great - in which case I have checked both patches in together with this ChangeLog entry: binutils/ChangeLog 2005-03-31 Nick Clifton <[EMAIL PROTECTED]> * configure.in: Add a check for providing a prototype for getopt() which is compatible with the one in include/getopt.h. If so then define HAVE_DECL_GETOPT. * configure: Regenerate. * config.in (HAVE_DECL_GETOPT): Add. * aclocal.m4: Regenerate. * addr2line.c: Include "config.h" before "bfd.h" so that HAVE_DECL_GETOPT is defined before getopt.h is included. But terminated at: In file included from /usr/home/wanderer/pkg/build/binutils/src/src/gas/as.h:93, from /usr/home/wanderer/pkg/build/binutils/src/src/gas/app.c:30: /usr/home/wanderer/pkg/build/binutils/src/src/gas/../include/getopt.h:116: warning: function declaration isn't a prototype OK - please try the attached patch for the GAS build problems. (It is basically the same as the one for binutils). If that works I can send you one for LD as well. Cheers Nick Index: gas/configure.in === RCS file: /cvs/src/src/gas/configure.in,v retrieving revision 1.174 diff -c -3 -p -r1.174 configure.in *** gas/configure.in30 Mar 2005 02:55:13 - 1.174 --- gas/configure.in31 Mar 2005 14:43:54 - *** GAS_CHECK_DECL_NEEDED(errno, f, int f, [ *** 716,721 --- 716,731 #endif ]) + AC_MSG_CHECKING(for a known getopt prototype in unistd.h) + AC_CACHE_VAL(gas_cv_decl_getopt_unistd_h, + [AC_TRY_COMPILE([#include ], [extern int getopt (int, char *const*, const char *);], + gas_cv_decl_getopt_unistd_h=yes, gas_cv_decl_getopt_unistd_h=no)]) + AC_MSG_RESULT($gas_cv_decl_getopt_unistd_h) + if test $gas_cv_decl_getopt_unistd_h = yes; then + AC_DEFINE([HAVE_DECL_GETOPT], 1, + [Is the prototype for getopt in in the expected format?]) + fi + GAS_CHECK_DECL_NEEDED(environ, f, char **f, $gas_test_headers) GAS_CHECK_DECL_NEEDED(ffs, f, int (*f)(int), $gas_test_headers) GAS_CHECK_DECL_NEEDED(free, f, void (*f)(), $gas_test_headers) Index: gas/config.in === RCS file: /cvs/src/src/gas/config.in,v retrieving revision 1.21 diff -c -3 -p -r1.21 config.in *** gas/config.in 30 Mar 2005 02:55:12 - 1.21 --- gas/config.in 31 Mar 2005 14:43:54 - *** *** 318,320 --- 318,323 /* Define to `unsigned' if does not define. */ #undef size_t + + /* Is the prototype for getopt in in the expected format? */ + #undef HAVE_DECL_GETOPT ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/806] Addr2line ignores the DWARF DW_AT_ranges attributes
Hi Fred, Proposed patch to fix the reported problem This patch is approved - please apply. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BinUtils built with arm and elf bfd support
Hi Raymond, I'm trying to build the binutils and gcc wirh arm and elf support. I have tried the following targets with no success: --target=arm-*-elf* --target=arm-*-elf --target=arm9e-*-elf The build and host system is i686-pc-cygwin. I hope that you were not literally including those asterisks as part of the target. The following should work for you: /configure --target=arm-elf Note - I am assuming that you are building in a separate directory to the sources. This is not a requirement for binutils, but it is good practice. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: need help
Hi Kiran, i wanted to run a small program on MPC8560 processor i wrote a small application and i cross compile with PPC_82xx-gcc i got a obj file as a.out I hope that you mean that you obtained an executable called "a.out". An object file is just the output of the assembler. It has not been linked with the necessary libraries and so cannot be executed on its own. even if i changed the code in my application the final "a.out"is showing the same size Small changes in your application's code will probably not change the size of the a.out executable. This is because the linker will pad it out so that it fits into a whole number of pages of memory. Large changes to your application most certainly will change the size of the executable however. * will the out put file(a.out) work only if there is a OS on the target? In general yes. Applications need some kind of operating system support in order to be able to run. It is possible to build a completely self contained executable however which needs no outside OS support. This is usually quite a complex task however, and requires intimate knowledge of the hardware upon which the application is going to run. should i need to do linking manualy or it is don automaticaly with gcc As long as you are not using the -c, -S or -E command line switches to gcc it will try to perform the linking step for you. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/835] New: Fails to build in 64bit mode
Hi Francois, binutils-2.15 does not compile in 64bit mode due to the fact that, starting in AIX5.2, in 64bit, we do not support the old format of vm-info and core-dump. I made changes in bfd/rs6000-core.c that I can provide you with, basically #ifdef ing out the references to the "old" part of the core-dump and vm-info unions. It would be nice if you could provide us with this patch, but it would be even better if there was some way to determine whether the old code was needed, say because the host was a pre-AIX5.2 system, and so only use the code under those circumstances. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/818] New: error handling %farg[0-4] registers
Hi Eric, Hi David,
When gas encounters the statement:
fldws -4(%r22),%farg0
it issues the error:
Error: Field out of range [0..31] (-59).
Error: Invalid operands
similarly for %farg1, %farg2, and %farg3, it issues similar warnings with -58,
-57, and -56 as the constant.
HP's native assembler accepts the statement. When I disassemble the output of
the native assembler, it converted that statement to:
fldw -4(,r22),fr4
So it appears %farg0 should be a synonym for %fr4. As a workaround, I've
modified my code to use %fr[4-7] instead of %farg[0-3] and gas is happy with
this.
This bug is present in binutils-2.15 and in the binutils-050404 snapshot I just
tested.
The patch below appears to fix this problem, but I am not an expert on
the HPPA instruction set - David - do you think that the patch is OK ?
Cheers
Nick
gas/ChangeLog
2005-04-11 Nick Clifton <[EMAIL PROTECTED]>
PR gas/818
* config/tc-hppa.c (pre_defined_registers): Fix %farg[0-3]
synonyms.
Index: gas/config/tc-hppa.c
===
RCS file: /cvs/src/src/gas/config/tc-hppa.c,v
retrieving revision 1.115
diff -c -3 -p -r1.115 tc-hppa.c
*** gas/config/tc-hppa.c3 Mar 2005 11:47:50 - 1.115
--- gas/config/tc-hppa.c11 Apr 2005 16:15:00 -
*** static int print_errors = 1;
*** 811,816
--- 811,817
%r26 - %r23 have %arg0 - %arg3 as synonyms
%r28 - %r29 have %ret0 - %ret1 as synonyms
+%fr4 - %fr7 have %farg0 - %farg3 as synonyms
%r30 has %sp as a synonym
%r27 has %dp as a synonym
%r2 has %rp as a synonym
*** static const struct pd_reg pre_defined_r
*** 854,863
{"%dp",27},
{"%eiem", 15},
{"%eirr", 23},
! {"%farg0", 5},
! {"%farg1", 6},
! {"%farg2", 7},
! {"%farg3", 8},
{"%fr0",0 + FP_REG_BASE},
{"%fr0l", 0 + FP_REG_BASE},
{"%fr0r", 0 + FP_REG_BASE + FP_REG_RSEL},
--- 855,864
{"%dp",27},
{"%eiem", 15},
{"%eirr", 23},
! {"%farg0", 4 + FP_REG_BASE},
! {"%farg1", 5 + FP_REG_BASE},
! {"%farg2", 6 + FP_REG_BASE},
! {"%farg3", 7 + FP_REG_BASE},
{"%fr0",0 + FP_REG_BASE},
{"%fr0l", 0 + FP_REG_BASE},
{"%fr0r", 0 + FP_REG_BASE + FP_REG_RSEL},
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: assemby code msp430
Hi Aditya, i am using the msp430-as assembler with -mmcu=msp430x147. the above controller has a code address space from 0x8000. but whenever i include ".org 0x8000" at the beginning of the code and follow it with a mov command like mov #0x5A80,0x0120, i get the output "operand out of range: 32784 (or a similar number)" I asked Dmitry, the MSP430 maintainer about this. He said: : The actual asm message will be 'region text is full' cause .org : directive will (as I understand) shift a PC by 0x8000 bytes forward : from the current location. The linker script defines ROM_START at : 0x8000, therefore first instruction will be placed at address 0x8000 + : 0x8000 == 65536 which is out of range. : : The assembler instruction mov #0x5A80,0x0120 will not produce any : error message unless some of operands over 16 bits value. If they are, : the error message will suggest how to fix this problem. Objdump : output will indicate that mov instruction uses PC relative addressing : mode and will show an actual address of the destination operand. : : I probably know where these question come from: some commercial tools : treat '.org' directive as an absolute shift within a whole memory : range. Thus, some people think that there is a bug, then think to read : documentation :) I hope that this helps. Basically, I think that Dmitry is saying that you do not need the ".org 0x8000" directive as this is already handled by the linker script. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: "No room for program headers" strikes again
Hi Stelios, Sorry. It's a suse 8.1 (quite old) with gcc 3.4-core compiled from source, at x86. ld --version gives 2.12.90.0.15 20020717 (SuSE) The code I'm trying to compile is made with a code generator and it's indeed rather huge. It has thousands of functions in one huge file,several sections and with debugging data the final file is about 2MB. So it could indeed require much space for "program headers". The question is, custom ld script the only solution? Not necessarily. You are using a very old version of the linker. If you update to the current release (v2.15) or even the current development sources, you may well find that the problem is resolved. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/841] mips64-elf-readelf was crashed by EABI64 binary.
Hi Monaka, Do you have a small testcase with which we can reproduce this failure and test any fixes ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/845] New: GAS .rept pseudo op-code
Hi Jaydeep, Following code generates error, .rept 2 .irp m1 1,2 .long \m1 .endr .endr ***Error: unexpected end of file in irp or irpc For which target ? I was unable to reproduce this failure using the current sources in the CVS and an x86 targeted version of GAS. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/850] New: linker issued assertion failure elf64-ppc.c:7771
Hi Robert, The problem caught is about error during linking of executable. /usr/bin/ld: BFD 041202 20041202 assertion fail elf64-ppc.c:7771 Please could you provide a simple way to reproduce this problem. This error msg is repeated many times. ld -V GNU ld version 041202 20041202 You may find that a newer version of the linker has fixed this problem. Would you care to try the current sources in the binutils CVS repository ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/847] New: Error: Zero-length symbol is illegal
Hi Andreas,
The ia64 assembler is choking on `.file ""' with the error message
"Zero-length symbol is illegal". According to the GAS manual this should
be allowed. The problem is that gcc 3.4 and later now uses `.file ""' instead
of `.file ""' when input comes from stdin.
Hmm, well the documentation does also say that the feature is only
supported for backwards compatibility and may go away in the future.
Still a patch for this problem seems fairly straight forward.
Jan, Ian - what do you think of this ?
Cheers
Nick
gas/ChangeLog
2005-04-15 Nick Clifton <[EMAIL PROTECTED]>
PR gas/847
* read.c (s_app_file): Call tc_convert_file_name, if defined,
before s_app_file_string.
* config/tc-ia64.c (ia64_convert_file_name): Define. Convert
empty file names into "".
* config/tc-ia64.h (tc_convert_file_name): Define.
Index: gas/config/tc-ia64.c
===
RCS file: /cvs/src/src/gas/config/tc-ia64.c,v
retrieving revision 1.152
diff -c -3 -p -r1.152 tc-ia64.c
*** gas/config/tc-ia64.c5 Apr 2005 04:01:12 - 1.152
--- gas/config/tc-ia64.c15 Apr 2005 11:39:41 -
*** ia64_canonicalize_symbol_name (name)
*** 8031,8036
--- 8031,8049
return name;
}
+ /* Avoid producing error messages about zero-length symbol names when
+GCC produces directives like:
+ .file ""
+by converting empty names into . */
+
+ char *
+ ia64_convert_file_name (char * name)
+ {
+ if (name != NULL && * name == 0)
+ return "";
+ return name;
+ }
+
/* Return true if idesc is a conditional branch instruction. This
excludes
the modulo scheduled branches, and br.ia. Mod-sched branches are
excluded
because they always read/write resources regardless of the value
of the
Index: gas/config/tc-ia64.h
===
RCS file: /cvs/src/src/gas/config/tc-ia64.h,v
retrieving revision 1.38
diff -c -3 -p -r1.38 tc-ia64.h
*** gas/config/tc-ia64.h 3 Mar 2005 11:47:52 - 1.38
--- gas/config/tc-ia64.h 15 Apr 2005 11:39:41 -
*** extern void ia64_dwarf2_emit_offset PARA
*** 120,125
--- 120,126
extern void ia64_check_label PARAMS ((symbolS *));
extern int ia64_estimate_size_before_relax (fragS *, asection *);
extern void ia64_convert_frag (fragS *);
+ extern char * ia64_convert_file_name (char *);
#define md_end() ia64_end_of_source ()
#define md_start_line_hook() ia64_start_line ()
*** extern void ia64_convert_frag (fragS *);
*** 132,137
--- 133,139
#define md_parse_name(s,e,c) ia64_parse_name (s, e, c)
#define tc_canonicalize_symbol_name(s)ia64_canonicalize_symbol_name
(s)
#define tc_canonicalize_section_name(s) ia64_canonicalize_symbol_name
(s)
+ #define tc_convert_file_name(s) ia64_convert_file_name (s)
#define md_optimize_expr(l,o,r) ia64_optimize_expr (l, o, r)
#define md_cons_align(n) ia64_cons_align (n)
#define TC_FORCE_RELOCATION(f)ia64_force_relocation (f)
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/867] New: Compilation errors for binutil-2.14 on RedHat 7.2
Hi Vivekk, I am getting to compilation errors for binutils-2.14. FYI: This is an old release of binutils. We are now at 2.15 and version 2.16 is about to be released. localealias.c:337: void value not ignored as it ought to be localealias.c:341: void value not ignored as it ought to be Am I missing anything? It appears that you have a bad prototype for memcpy() somewhere in your include path. Both of these errors refer to the code in localealias.c looking at the return value from memcpy(). memcpy() does return a value so the error message is wrong, hence the probable cause is that the compiler has been given a bad prototype. What happens for example if you add this line: extern void * memcpy (void *, const void *, size_t); at the start of the code for read_alias_file() in intl/localealias.c ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Linker mapfile shows strange addresses
Hi Hartmut, I'm using an m68k-elf-ld linker (GNU ld version 2.14 20030612) and relocating sections to a different load address with AT. As the linker script file for doing this is not so easy to write, I'm often looking at the mapfile generated by ld to verify that I'm doing everything correct. There have been several bugs relating to mapfile generating and section layout by the linker since release 2.14, so I would suggest upgrading to release 2.15, or even better - the almost ready for release 2.16 version. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/868] New: bfd leaks memory in several places
Hi John,
bfd has several memory leaks. I'm fixing the ones in dwarf2.c, but a simple grep
for 'bfd_realloc' shows several obvious leaks on failure:
./bfd/bfdio.c:bim->buffer = bfd_realloc (bim->buffer, newsize);
[etc]
The least intrusive way to resolve most of these would be to provide a
new function called, say, bfd_realloc_or_free() which could used to
replace most of the calls to bfd_realloc. It could be implemented like
this:
Index: bfd/libbfd.c
===
RCS file: /cvs/src/src/bfd/libbfd.c,v
retrieving revision 1.38
diff -c -3 -p -r1.38 libbfd.c
*** bfd/libbfd.c4 May 2005 15:53:33 - 1.38
--- bfd/libbfd.c5 May 2005 14:32:21 -
*** bfd_realloc (void *ptr, bfd_size_type si
*** 180,185
--- 180,214
return ret;
}
+
+ /* Reallocate memory using realloc.
+If this fails the pointer is freed before returning. */
+
+ void *
+ bfd_realloc_or_free (void *ptr, bfd_size_type size)
+ {
+ size_t amount = (size_t) size;
+ void *ret;
+
+ if (size != amount)
+ ret = NULL;
+ else if (ptr == NULL)
+ ret = malloc (amount);
+ else
+ ret = realloc (ptr, amount);
+
+ if (ret == NULL)
+ {
+ if (amount > 0)
+ bfd_set_error (bfd_error_no_memory);
+
+ if (ptr != NULL)
+ free (ptr);
+ }
+
+ return ret;
+ }
+
/* Allocate memory using malloc and clear it. */
void *
What do you think ?
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: GNU binutils strip and option -s (strip debuginfo) from ld don't work.
Hi Jernej, It is a known issue that the GNU binutils strip and option -s (strip debuginfo) from ld don't work. No. Can you provide some more information about the failure please ? * Which version of strip and ld ? * What is the failure ? * For which host and for which target ? * Can you provide a small testcase that demonstrates the failure ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Assertion failed in linker
Hi Jan, I apologise for taking so long to reply to your email. I am running binutils binutils-2.16.90.0.2-2mdk (Mandrake Cooker). After upgrade from 2.15.x series which Mandrake used before, I am getting this error on linking: collect2: ld terminated with signal 11 [Segmentation fault] /usr/bin/ld: BFD 2.16.90.0.2 20050429 assertion fail elflink.c:6191 If needed, I can put the binaries online for investigation. Yes please. Can you also tell us what host and target you were using ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/947] Extension to BFD and addr2line to print inlining chain
Hi Fred, Created an attachment (id=487) --> (http://sources.redhat.com/bugzilla/attachment.cgi?id=487&action=view) Patch to implement unwinding of inlining chains This patch is approved - please check it in, but with one addition: Please could mention the new feature of addr2line in the binutils/NEWS file ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld -wrap does not apply to symbols referenced in same file as the symbol's defintion
Hi Steve, This is request to binutils to fix -wrap to work properly with all symbol references. This would be a useful feature but unless you want to implement it yourself I think that it might be quite a long time before somebody decides to have a go at it. I am sorry to be so pessimistic, but since this is a feature request rather than a bug report I think that it is unlikely to receive any immediate attention. Of course there are companies out there that will happily write this enhancement for you, if you pay them, or it might even make a good job to give to a trainee or intern to give them some experience of the gcc toolchain. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: PA-RISC bug in gas
Hi Dan, Hi - I'm trying to use gas 2.15 on PA-RISC, and I want to issue an ldcws instruction like: ldcws,co 0(%r20), %r19 which is accepted by the HP assembler, but gas barfs with: Error: Invalid Short Load/Store Completer. gas apparently doesn't like the cache control hint completor, which is critical for semaphore performance on PA-RISC. I've tried every reasonable combination of characters for the completer that I can think of, and nothing seems to work. I passed this question and your proposed patch onto the HPPA binutils port maintainer. This is what he had to say about it: : One problem is you are mixing PA 1.x and 2.0 assembler semantics. : The co completer is a PA 2.0 feature. PA 1.x processors don't : support this completer. The PA 2.0 semantics is ldcw,co. I guess : the HP assembler accepts ldcws as a synonym for ldcw when generating : PA 2.0 code. : I suspect that if Dan changes ldcws to ldcw and specifies .level : correctly, the assembler will accept the co completer. I hope that this helps. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Error in _fixunsdfsi for m68040
Hi Mario, I can't build a 68k C cross compiler under cygwin starting from: binutils-2.16 newlib-1.13.0 gcc-4.0.0 because an error compiling libgcc2.c in function _fixunsdfsi for M68040 Using binutils-2.15 there is no more error and the generated 68k cross compiler works properly. This should now work if you use the very latest binutils sources from the mainline of the binutils CVS repository. It was reported as bug 991 and I have just checked in the patch that was submitted to fix it. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld/genscripts.sh: test: argument expected
Hi Alexander, Trying to build arm-elf (from sparc-solaris) I got the following error: LIB_PATH='' /bin/sh ../../binutils-2.16.1/ld/genscripts.sh ../../binutils-2.16.1/ld /home/sw/ask/gnuarm/lib "/home/sw/ask/gnuarm" sparc-sun-solaris2.8 arm-unknown-elf arm-elf "armelf" "/usr/local/lib /lib /usr/lib" no armelf "arm-elf" ../../binutils-2.16.1/ld/genscripts.sh: test: argument expected It can be fixed with the following patch: Thanks very much for submitting this patch. I have applied it together with this ChangeLog entry: ld/ChangeLog 2005-06-16 Alexander Klimov <[EMAIL PROTECTED]> * emultempl/armelf.em: Add quotes to avoid a null test expression. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: reg graphs
Hi Nithya, Is it possible for us to draw the graph that shows the cpu utilization during the various time intervals. It is not clear what you mean by "CPU utilization" here. gprof tool gives us the CPU utilization of the various functions. No it does not. It shows you how the CPU time that was consumed by the program was divided up amongst the functions that make up that program. I want the CPU utilization for the whole interval for the various time periods Are you referring to how much CPU time a given program is using over specific time periods ? In which case a tool like "ps" or "top" can probably give you the information you need. Or maybe you want to see a graph of which function was consuming CPU cycles at any given point in time ? This information is recorded in the gmon.out file produced by a profiled program, and the format of this file is documented. (See gprof/gprof.texi). You will probably have to write your own tool to extract this information in the format that you desire. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD 2.16.1 "assertion failure" and "internal error"
Hi Dan, BFD: BFD 2.16.1 assertion fail ../../binutils-2.16.1/bfd/coff-alpha.c:606 BFD: BFD 2.16.1 internal error, aborting at ../../binutils-2.16.1/bfd/coff-alpha.c line 635 in alpha_adjust_reloc_in The details of the bug are here: http://sourceware.org/bugzilla/show_bug.cgi?id=1030 Note having a suitable c++ compiler to hand I am having difficulty generating the object files in order to reproduce this problem. Would it be possible for you to place a tarball of a.o, b.o and c.o somewhere where I could access it ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD bug with elf*-sparc sections?
Hi Dan, Using the source files and Makefile I posted to the web: http://www.cs.cornell.edu/marques/bfdexample/a.cxx http://www.cs.cornell.edu/marques/bfdexample/c.cxx http://www.cs.cornell.edu/marques/bfdexample/Makefile I do not have access to the SUNPro C++ compiler, so would it be possible for you to make the .o files available as well please ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD 2.16.1 "assertion failure" and "internal error"
Hi Dan, The standard ALPHA_MAGIC number is 0x183. However, the DEC C and C++ compilers can generate compressed binary files, whose magic number will be 0x188. Ah ha! An alternative would be to use the 'objZ -u' command to uncompress the .o file. Presumably, this could be done automatically from within the BFD library. Hmm - this might be tricky. What if the objZ program is not available ? What if I am running on a non-DEC ALPHA host and I want to examine/use object files created in this compressed format ? Is the compression scheme used by DEC documented ? Is there source code available for it ? I think that the simplest change we could make would be to have BFD detect object files with a magic number of 0x188 and then have it issue an error message along the lines of "please decompress this file before passing it to BFD". What do you think ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: BFD 2.16.1 "assertion failure" and "internal error"
Hi Dan,
I think that the simplest change we could make would be to have BFD
detect object files with a magic number of 0x188 and then have it
issue an error message along the lines of "please decompress this file
before passing it to BFD". What do you think ?
This makes sense, so I've attached a patch that does just this.
Let me know when/if you incorporate it to the cvs tree, and when the
patch that you proposed makes it in.
I have now checked both your patch in and mine as well.
Cheers
Nick
bfd/ChangeLog
2005-07-14 Daniel Marques <[EMAIL PROTECTED]>
Nick Clifton <[EMAIL PROTECTED]>
* coff-alpha.c (alpha_ecoff_bad_format_hook): Detect compressed
Alpha binaries and issue a helpful error message.
(alpha_ecoff_swap_reloc_out): Increase maximum allowed internal
symbol index to 15 to allow for binaries produced by DEC
compilers.
include/coff/ChangeLog
2005-07-14 Daniel Marques <[EMAIL PROTECTED]>
* alpha.h (ALPHA_ECOFF_COMPRESSEDMAG): Define.
* ecoff.h (ALPHA_MAGIC_COMPRESSED): Define.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/1069] Segmentation fault in libiberty/xexit.c:51
Hi Guys, Alan wrote: No, this is a buffer overflow of gas/config/tc-crx.c:ins_parse in reset_vars. And I am applying this patch to stop the overflow and prevent the seg-fault. (This also makes the patch applied for 1063 redundant, but that should not matter). Cheers Nick gas/ChangeLog 2005-07-14 Nick Clifton <[EMAIL PROTECTED]> PR 1069 * config/tc-crx.c (reset_vars): Use strncpy to prevent overflowing the ins_parse buffer. Index: gas/config/tc-crx.c === RCS file: /cvs/src/src/gas/config/tc-crx.c,v retrieving revision 1.15 diff -c -3 -p -r1.15 tc-crx.c *** gas/config/tc-crx.c 7 Jun 2005 17:54:16 - 1.15 --- gas/config/tc-crx.c 14 Jul 2005 15:33:26 - *** reset_vars (char *op) *** 268,274 memset (& output_opcode, '\0', sizeof (output_opcode)); /* Save a copy of the original OP (used in error messages). */ ! strcpy (ins_parse, op); } /* This macro decides whether a particular reloc is an entry in a --- 268,275 memset (& output_opcode, '\0', sizeof (output_opcode)); /* Save a copy of the original OP (used in error messages). */ ! strncpy (ins_parse, op, sizeof ins_parse - 1); ! ins_parse [sizeof ins_parse - 1] = 0; } /* This macro decides whether a particular reloc is an entry in a ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Misinterpretation of PE export address table entries
Hi Pavel, pe_print_edata() thinks the RVA is a forwarder when it points between the start of export tables (from the data dictionary) and the end of the *whole section* containing the tables. This is wrong. It should use the length in the data directory to determine the end of area occupied by export tables. See the attached patch. Thanks for the patch. I think that it is small enough to be considered as obvious and so not need a copyright assignment. Thus I have applied it together with this ChangeLog entry: bfd/ChangeLog 2005-07-29 Pavel Kankovsky <[EMAIL PROTECTED]> * peXXigen.c (pe_print_edata): Compute the size of the export table from the size field in the DataDictionary and not the size of the section. Some linkers embed the export table inside a larger section. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: binutils 2.16.1: objcopy broken on solaris x86?
Hi Andrew, < LOAD off0x vaddr 0x paddr 0x align 2**16 > LOAD off0x vaddr 0x paddr 0x align 2**12 According to the solaris linker and library guide http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl2a?a=view#chapter6-34713 p_align should be 2**16 for 32 bit segments, and 2**20 for 64 bit segments. There seems to be a little inconsistency here, because on x86-64, the solaris linker generates p_align as 2**16, but the solaris documentation suggests it should be 2**20. Either way, the p_align values after objcopy do not meet the requirements. [I do not have access to an x86 Solaris 10 environment, so the following is guesswork]. For the 32-bit case I think that the problem might be because of this definition in the file ld/emulparams/elf_i386_ldso.sh: MAXPAGESIZE=0x1000 If you change this to: MAXPAGESIZE=0x1 and then rebuild the linker, does the (32-bit) problem go away ? (We will need to make a different version of this file for Solaris if this is so, but that can be done later). You may also find that it is necessary to change the definition of ELF_MAXPAGESIZE in bfd/elf_i386.c: #define ELF_MAXPAGESIZE 0x1000 I am not sure about the 64-bit case though. so lets leave that for now. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: what about new feature for objcopy
Hi Victor, I'd like to have the following feature in objcopy: 1) set FUNCTION attribute for some symbol or other attributes 2) set/correct size for some symbol (e.g. function) In other words, I'd like to have simple command-line interface to correct symbol table of objects. This would indeed by a nice feature. Please feel free to write a patch that implements it, although if you wanted to submit it we would first need a copyright assignment to the FSF. Is there a particular reason why you want such a feature ? Perhaps there is another way of solving the problem you are facing, possibly by editing the assembler files before they are converted into object files. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Objdump missinterpretes padding bytes
Hi Dominic, I'm using objdump as a preprocessor for a tool which analyzes a binary's assembly and discovered that a jump instruction in the libc function "strrchr" has no target or rather the target lies within an instruction. Objdump missinterpretes 3 padding bytes and thus creates incorrect disassembly output: Thanks very much for submitting this bug report and the patch. I have asked the x86 binutils maintainers about but unfortunately they feel that the patch is not appropriate. The whole question of how to start disassembly at a wrong address is a difficult one to solve and this patch only addresses a small subset of the problem. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: what about new feature for objcopy
Hi Victor, Thanks for your e-mail. I really need such a feature because some libraries on Linux (for example Intel/IPP 4.1) contain some external functions like names and without correct sizes. Really if these libraries contain incorrect information and they are distributed in a binary-only format then you should complain to the people distributing them. They should not be distributing broken libraries. One alternative is to use a hex editor to change the sizes directly. Of course this does mean that you will need to locate where those sizes are held in the binary, which is not that easy since the symbol structure stores its name as an index into a string section. You would have to compute the relevant index, then search for that binary pattern in the symbol table section and then look at the appropriate offset from the index for the size and check to see that it is the current (bad) value before modifying it. But implementation, I am sure is very simple. he he - funny joke. Seriously things like this are rarely simple although it may appear that way at first. For example the syntax for a general symbol editing command line switch would have to be pretty complicated. Changing the name, size, value, attributes, section etc. Of course you just want to change the size you could have: --set-symbol-size SYM=SIZE But the real problem is time - or rather lack of it. It would be nice to implement such a feature but I just do not have the time to do it. Maybe somebody else will volunteer, but if not then it will be up to you. Sorry, I know that is not what you want to hear, but that is the way that it is. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: issue with -R option coupled with -Xlinker gcc option
Hi Michael, Arm-elf-ld version : 2.15 This is probably your problem. Please try upgrading to the latest released version of the binutils (2.16) or failing that, please try using the current mainline sources in the CVS repository. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: found vuln in bfd lib Coff code
Hi ICBM,
Found a new vuln in bfd lib coff code and similar with the last
one...
In the do_slurp_coff_armap() funciton:
static bfd_boolean
do_slurp_coff_armap (bfd *abfd){
¡
carsym_size = (nsymz * sizeof (carsym)); //uses the nsymz from file
ptrsize = (4 * nsymz); //integer overflow here
¡
/* Allocate and read in the raw offsets. */
raw_armap = bfd_alloc (abfd, ptrsize); // allocate wrong memory size
here
if (raw_armap == NULL)
goto release_symdefs;
¡
}
I do not understand why this can lead to a vulnerability. Even if the
computation of "ptrsize" does overflow all that will happen is that the
code will read in too little of the archive's map. The code in
bfd_alloc() treats the size parameter as unsigned and it copes with a
very large value which is too big to be allocated. So where is the
vulnerability ?
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: infinate loop in as with .org pseudo
Hi Dan,
Given this as input (three lines):
foo = .
.org foo+16
foo = .
GNU as (with no special command-line options) apparently goes into an
infinate loop.
Not surprising really since that is a pathological piece of code. Still
infinite loops are bad things, so please could you try out the attached
patch and let me know if it works for you.
Cheers
Nick
Index: gas/write.c
===
RCS file: /cvs/src/src/gas/write.c,v
retrieving revision 1.93
diff -c -3 -p -r1.93 write.c
*** gas/write.c 11 Aug 2005 01:25:20 - 1.93
--- gas/write.c 17 Aug 2005 17:50:01 -
*** relax_segment (struct frag *segment_frag
*** 1731,1737
/* For each frag in segment: count and store (a 1st guess of)
fr_address. */
address = 0;
! for (fragP = segment_frag_root; fragP; fragP = fragP->fr_next)
{
fragP->relax_marker = 0;
fragP->fr_address = address;
--- 1732,1740
/* For each frag in segment: count and store (a 1st guess of)
fr_address. */
address = 0;
! for (frag_count = 0, fragP = segment_frag_root;
!fragP;
!fragP = fragP->fr_next, frag_count ++)
{
fragP->relax_marker = 0;
fragP->fr_address = address;
*** relax_segment (struct frag *segment_frag
*** 1807,1812
--- 1810,1816
/* Do relax(). */
{
+ unsigned long max_iterations;
offsetT stretch; /* May be any size, 0 or negative. */
/* Cumulative number of addresses we have relaxed this pass.
We may have relaxed more than one address. */
*** relax_segment (struct frag *segment_frag
*** 1815,1820
--- 1819,1838
grew, and another shrank. If a branch instruction doesn't fit anymore,
we could be scrod. */
+ /* We want to prevent going into an infinite loop where one frag grows
+depending upon the location of a symbol which is in turn moved by#
+the growing frag. eg:
+
+ foo = .
+ .org foo+16
+ foo = .
+
+ So we dictate that this algorithm can be at most O2. */
+ max_iterations = frag_count * frag_count;
+ /* Check for overflow. */
+ if (max_iterations < frag_count)
+ max_iterations = frag_count;
+
do
{
stretch = 0;
*** relax_segment (struct frag *segment_frag
*** 2035,2042
}
} /* For each frag in the segment. */
}
! while (stretched);/* Until nothing further to relax. */
! } /* do_relax */
ret = 0;
for (fragP = segment_frag_root; fragP; fragP = fragP->fr_next)
--- 2053,2063
}
} /* For each frag in the segment. */
}
! while (stretched && -- max_iterations); /* Until nothing
further to relax. */
!
! if (stretched)
! as_fatal (_("Infinite loop encountered whilst attempting to compute the
size of section %s"), segment_name (segment));
! }
ret = 0;
for (fragP = segment_frag_root; fragP; fragP = fragP->fr_next)
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: infinate loop in as with .org pseudo
Hi Dan, I added a declaration for frag_count to your patch and it successfully issues an error on this code (and also on the original source from which this code was simplified). Great - in which case I will check the patch in along with this entry in the ChangeLog: gas/ChangeLog 2005-08-18 Nick Clifton <[EMAIL PROTECTED]> * write.c (relax_segment): Count the number of frags being processed and use this to compute a maximum limit on the number of iterations that will be allowed when attempting to relax the segment. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: alpha linux: R_ALPHA_LITERAL relocation overflow
Hi Mike, I submitted this to bugzilla last week, but I didn't know who to assign it to, and I wanted it to get more exposure. If I'm posting this to the wrong place, I apologize: No this is the right place for such questions, although you may find that posting to "[EMAIL PROTECTED]" is more effective as more people read that (parallel) list. Anyway I was hoping that an Alpha expert would respond to your email, but nobody has stepped forward so instead you get me... I suspect there might be an overflow bug related to the R_ALPHA_LITERAL relocation type in binutils, but I cannot be certain. If this is happening then it is happening in the assembler, which is the program that is choosing to generate the R_ALPHA_LITERAL reloc. Have a look at the load_expressions() function in the binutils source file gas/config/tc-alpha.c. You will need to search for BFD_RELOC_ALPHA_ELF_LITERAL as this is what the reloc is called there. I suspect however that this might actually be a compiler problem, or even a user problem. What I think might be happening is that the compiler is creating code that assumes that __divqu function will be within the 16-bit offset available to the R_ALPHA_LITERAL and telling the assembler to go ahead and generate the reloc. Presumably this used to be OK when the libafs library was smaller, but now that it has grown this assumption is no longer true. If this is correct then the next question to answer is whether the compiler is making this bogus assumption on its own, or if the user has told it (implicitly or explicitly) that such an assumption is valid. I am thinking here of the gcc switches -msmall-data/-mlarge-data/ -msmall-text/-mlarge-text. Maybe one of these needs to specified on the command line when compiling libafs. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld relocate symbols(in small common section) to a unaligned address.(on mips r3000 target)
Hi Zhigang, /home/zhigang/0808/pattern_install/lib/extras.o 0x8090bc4d piofree_handle --Please see here, the address is not correct aligned .comm piofree_handle,4,4(the alignment is right) This does indeed appear to be a bug in the linker. Are you able to create a *small* test case which reproduces this problem ? With that we could investigate it and try to fix it. Oh - one other thing you could try is to download the current binutils sources from the mainline of the CVS repository and build a new linker. Several rather subtle and nasty linker bugs have been fixed recently and your problem might be one of those fixed bugs. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld relocate symbols(in small common section) to a unaligned address.(on mips r3000 target)
Hi Zhigang, sorry i forgot to attach the file. Now attach the tar ball. Unfortunately you sent this huge attachment to the entire binutils mailing list, not just me. In the future please try not to do this. If you cannot create a small test case then please either just send the large test case only to the people who specifically request it, or else make it available via FTP or HTTP download. Anyway I downloaded the tarball, built a new mipsel-elf toolchain and tried to reproduce your problem. Unfortunately although I could build the executable the piofree_handle variable was correctly aligned: % grep piofree_handle fred.map piofree_handle 0x4 extras.o 0x8090b490piofree_handle By the way have you tried using objdump to verify that the piofree_handle is misaligned and that the bug is not just in the addresses being reported in the map file ? % objdump --syms fred | grep piofree_handle 8090b490 g O .sbss 0004 piofree_handle I was using a toolchain built from yesterday's gcc and binutils sources. Since you say that you have reproduced this problem using an 050907 set of the binutils sources I can only conclude that either: * The bug is in binutils and it has been fixed in the last few days. * The bug is in the libgcc.a, libc.a or libsupc++.a libraries that are included via the target.ld script. Have you tried rebuilding these libraries ? * The bug is connected with the host machine being used to run the toolchain. I was using a x86 box with Red Hat Enterprise Linux rel 3 installed on it and a host compiler which was a gcc 3.4 clone released by Red Hat called "GNUPro 04r2-2". Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld relocate symbols(in small common section) to a unaligned address.(on mips r3000 target)
Hi Zhigang, Hmm. I am basically using the same or very similar sources as you. All the sources are from checkouts from the various CVS repositories on 8 Sept 2005. The versions are binutils v2.16.91, gcc v4.1.0, and newlib v1.13.0. I also configured my toolchain in the same way as you, although I did not bother to install it. I just ran the test using the built toolchain. If the problem is still exist, I have to give up the gcc-4.0.1 with binutils-2.16.In my enviorments , gcc 3.4.4 with binutils-2.16.1 works very well. Ah - well now this is very interesting! So keeping the same version of binutils but reverting back to an older version of gcc solves the problem, yes ? This does tend to imply that the problem might be a gcc bug not a binutils bug. I also note that I am using gcc version 4.1.0 sources whereas you are using gcc versions 4.0.1 sources, so maybe this is a gcc bug which has been fixed in the latest gcc sources... Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld overwriting output sections???
Hi Jakub,
the kernel image is linked together correctly (line is present) or the
.mapped section overwrites the .unmapped section (line is not present).
When you say that it overwrites are you referring to the load-time
address (LMA) or the run-time address (VMA) or both ?
Is there anything wrong with our linking process or is it a bug in ld?
It does sound like a ld problem. Have you tried using the latest
sources from the CVS repository ? They may work. If not, please could
you put together a small test program (assembler source, linker script,
makefile) that demonstrates the problem so that we can investigate further ?
.mapped (((0x10 +0x8000) + 0x8000)+SIZEOF(.unmapped)): AT
(0x8000 +SIZEOF(.unmapped)) {
Presumably this line is the culprit, and at a guess I would assume that
the SIZEOF() operator is not working properly.
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: binutils and libiberty.h
Hi Pierre, I just compiled without problem binutils 2.16.1. But I noticed that the 'make install' didn't install the 'libiberty.h' file which is needed by some other apps. I would like to know if this is a normal situation or if I have misunderstood some things. It is probably the normal situation. If you run an explicit "make install-libiberty" do you get the header file installed ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/1391] New: objcopy trashes PE executable when using "add-gnu-debuglink"
Hi, Idx Name Size VMA LMA File off Algn 0 .gnu_debuglink 0018 0268 2**2 When using a native win32 "PE" editor/format tool like "LordPE" it lists some crap for the first section (containing debug link), all other sections seem ok: Seems objcopy is messing up the PE section table while adding gnu debug link. I seem to recall that the PE file format does not allow sections to start at address 0 and that this causes problems for debug sections. Probably the simplest way to fix this problem is to amend the PE linker script (ld/scripttempl/pe.sc) and add an explicit entry for the .gnu_debuglink section. If this works, please could you submit a patch so that we can apply it to the mainline sources. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Is this a ld bug?
Hi Vamsi, hidden symbol `__dso_handle' in /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/crtbegin.o is referenced by DSO collect2: ld returned 1 exit status is this a bug in binutils 2.14 ?? Almost certainly yes. Please try building a new linker using the current latest released sources (version 2.16) or, even better, the current CVS mainline sources. If you still have this problem using the new linker please could you generate and submit a small test case so that we can investigate further. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: assembler 'movl ss, (ebp)' produce an error for target i686
Hi Henry, * Bug: 'movl %ss, (%ebp)' produce an error for target i686 (32 bit): " Error: suffix or operands invalid for `mov' " I asked the x86 maintainers if they would look at this bug report. Here is what H.J.Lu had to say about it: ; There is no such a thing of moving between a segment register and a : 32bit memory location. : : The new i386/x86_64 assemblers no longer accept instructions for : moving between a segment register and a 32bit memory location, i.e., : : movl (%eax),%ds : movl %ds,(%eax) : : To generate instructions for moving between a segment register and a : 16bit memory location without the 16bit operand size prefix, 0x66, : : mov (%eax),%ds : mov %ds,(%eax) : : should be used. It will work with both new and old assemblers. The : assembler starting from 2.16.90.0.1 will also support : : movw (%eax),%ds : movw %ds,(%eax) : : without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are : available at : : http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch : http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch I hope that this makes things clear. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ObjDump Doc. Bug
Hi Bryce,
"reg-name-std" needs to be replaced with "reg-names-std"
So it does. I have committed the obvious patch (attached).
Cheers
Nick
binutils/ChangeLog
2005-10-10 Bryce Schober <[EMAIL PROTECTED]>
* doc/binutils.texi (objdump): Fix typo: -reg-name-std should be
-reg-names-std.
Index: binutils/doc/binutils.texi
===
RCS file: /cvs/src/src/binutils/doc/binutils.texi,v
retrieving revision 1.80
diff -c -3 -p -r1.80 binutils.texi
*** binutils/doc/binutils.texi 4 Oct 2005 11:03:38 - 1.80
--- binutils/doc/binutils.texi 10 Oct 2005 08:39:04 -
*** can be placed together into a comma sepa
*** 1714,1720
If the target is an ARM architecture then this switch can be used to
select which register name set is used during disassembler. Specifying
! @option{-M reg-name-std} (the default) will select the register names as
used in ARM's instruction set documentation, but with register 13 called
'sp', register 14 called 'lr' and register 15 called 'pc'. Specifying
@option{-M reg-names-apcs} will select the name set used by the ARM
--- 1714,1720
If the target is an ARM architecture then this switch can be used to
select which register name set is used during disassembler. Specifying
! @option{-M reg-names-std} (the default) will select the register names as
used in ARM's instruction set documentation, but with register 13 called
'sp', register 14 called 'lr' and register 15 called 'pc'. Specifying
@option{-M reg-names-apcs} will select the name set used by the ARM
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Bugs on binutils - verious SUNs . . .
Hi Peter, tonite I tried to compile the new version of binutils (2.16.1) on various SUN-Workstations without success. (1) First of all, there saemas to be a bug, if you use "./configure --prefix /usr/gnu" I got errors when typeing "make" in the sub directories "bfd" and "libiberty". Presumably you mean the messages about "libintl.h" not being found ? If so then you can add the "--disable-nls" switch to the configure command line and this should resolve the problem. I think that the actual bug is due to some strangeness with the installation of the intl package under Solaris (but I could be mistaken about this). (2) Question: Why is'nt there an uninstall feature, to get rid of previous releases? Because a simple recursive delete command will remove a release. Alternatively if you obtained the old binutils release via an RPM or some other kind of package managing tool you can always use the uninstall feature of that tool. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/1391] objcopy trashes PE executable when using "add-gnu-debuglink"
Hi, currently one can fix this manually by executing additional step: objcopy --change-section-vma .gnu_debuglink=+ test_xxx.exe I did a grep on the sources but could not really find a location where the wrong VMA might be produced.. Could this be a bug in bfd library itself? Yes, although I am not sure if an easy fix exists. In the meantime please could you try the attached patch which might work. The problem with it is that it has to guess as to the correct VMA value to use. I am not sure if matters though. It might be that any non-zero value will be valid, even if it overlaps with another section. Cheers Nick Index: binutils/objcopy.c === RCS file: /cvs/src/src/binutils/objcopy.c,v retrieving revision 1.87 diff -c -3 -p -r1.87 objcopy.c *** binutils/objcopy.c 3 Oct 2005 19:37:44 - 1.87 --- binutils/objcopy.c 11 Oct 2005 15:40:46 - *** copy_object (bfd *ibfd, bfd *obfd) *** 1349,1354 --- 1349,1361 bfd_nonfatal (gnu_debuglink_filename); return FALSE; } + + if (bfd_get_flavour (obfd) == bfd_target_coff_flavour) + /* Try to set the VMA of the section to some non-zero value so + that it will work for PE format files. (We have no way to + distinguish between COFF and PE flavours). If this does not + work, just ignore the failure. */ + bfd_set_section_vma (obfd, gnu_debuglink_section, 0xf000); } if (bfd_count_sections (obfd) == 0) ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: readelf patch: support non-standard section header sizes
Hi Ronald, Problem: when running readelf on ELF binaries that have a non-standard size for the Elf32_Ehdr.e_shentsize field (and thus non-standard size section headers), the sections are not correctly interpreted. Can you post a (small) example file that contains such non-standard sizes so that we can check readelf's behaviour please ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Bug in ar (all binutils version)
Hi Mario,
The bug is in arsup.c in function ar_save. The rename instead of smart_rename is
used. The smart_rename function take the operating system into account. This bug
is in all version of the binutils 2.11, 2.13, 2.14 and 2.15 under windows.
Are you sure about the problem existing in 2.15 ?
(Also there is a 2.16 binutils release which is out now, although the
code in arsup.c there is essentially the same as in 2.15).
> File: arsup.c
> #if defined (_WIN32) && !defined (__CYGWIN32__)
> smart_rename (ofilename, real_name, 0);
> #else
> rename (ofilename, real_name);
> #endif
The file binutils/ChangeLog for the 2.15 sources shows:
2004-04-09 Daniel Jacobowitz <[EMAIL PROTECTED]>
Merge from mainline:
2004-04-07 Benjamin Monate <[EMAIL PROTECTED]>
PR 86
* arsup.c (ar_save): Use smart_rename.
and the code for the function looks like this:
void
ar_save (void)
{
if (!obfd)
{
fprintf (stderr, _("%s: no open output archive\n"), program_name);
maybequit ();
}
else
{
char *ofilename = xstrdup (bfd_get_filename (obfd));
bfd_close (obfd);
smart_rename (ofilename, real_name, 0);
obfd = 0;
free (ofilename);
}
}
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/1568] New: COFF code section should be read only
Hi Vahur, To create object files which are link-compatible with MS Visual C, the "x" flag in .section directive should also set read only flag in COFF section. Otherwise MS linker will complain about multiple segments with different attributes and in fact will not merge such section with other code sections. I tracked down the problem to the function obj_coff_section in file config/obj- coff.c where line case 'x': flags |= SEC_CODE | SEC_LOAD; break; should be changed to case 'x': flags |= SEC_CODE | SEC_LOAD | SEC_READONLY; break; Read/write code sections are possible then by specifying "wx" as section attributes. Except that the "w" flag will be processed first, clearing the readonly bit and then the "x" flag will be processed, setting it. In order to obtain read/write code sections you would need to use "xw" as the flags. I agree that it makes sense to have code sections marked as readonly be default, but I am worried that making this change would break other tools which rely upon the current behaviour. Still if we make the "w" flag behave as you originally suggested it might be OK. Please could you try out the uploaded patch and see if it resolves the problem for you ? Cheers Nick gas/ChangeLog 2005-10-28 Nick Clifton <[EMAIL PROTECTED]> PR binutils/1568 * config/obj-coff.c (obj_coff_section): Set readonly flag with the 'x' attribute. Remember the actions of the 'w' and 'n' attributes and do not allow the 'x','s' or 'd' attributes to change them. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/1150] undefined reference to `_mpi_sgi_init'
Hi Michael, I ran into this one as well on IRIX-6.5.28m with gcc-4.0.1 and binutils-2.16.1. Why is this bug in status WAITING? Is more input required? I can provide testing and debugging if required. Can you provide a specification for these OPTIONAL symbols ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Incorrect check on assembly language register name
Hi Jean-Jacques, I think there is a mistake in the isoctal definition in the “gas/config/tc-sparc.c” file : #define isoctal(c) ((unsigned) ((c) - '0') < '8') There are simple quotes around the 8 while I think they should not be there Thanks for reporting this problem. I have applied your suggested fix along with this ChangeLog entry. Cheers Nick gas/ChangeLog 2005-11-08 Jean-Jacques Metayer <[EMAIL PROTECTED]> * config/tc-sparc.c (isoctal): Fix thinko. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/1150] undefined reference to `_mpi_sgi_init'
Hi Michael, I don't have any information beyond the error message and what I learned from the message to the mailing list quoted above. The behaviour of OPTIONAL symbols seems to be that they're silently ignored if not present in any of the linked objects, allowing for using libraries if linked against but working anyway if missing. In the case of libpthread this seems to silently recognize linkage against mpi and doing a call into mpi to make it aware of pthreads being used (or the like). Ok - this appears to be an Irix specific extension to the ELF spec. An extension which is not currently supported by the binutils. Do you have a *small* self-contained example that can reproduce the problem ? Preferably one that can be run using a cross-compiler as I do not have access to an Irix host. Failing that, can you supply a binary that contains one of these OPTIONAL symbols so that I can investigate further ? In the meantime if you would like to try out the patch I am uploading to the PR, you may find, just possibly, that it helps. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/1150] undefined reference to `_mpi_sgi_init'
Hi Michael, Okay, I gave it a try to build a testcase. It's included in the attachment. Thanks. I was not able to run all of the tests in your testcase, since I do not have the Irix system libraries available, but I was able to reproduce the linker error message about undefined symbols and I have produced a tentative patch that might allow give you a working GNU linker. The patch does not implement all of the spec for OPTIONAL symbols. I hope that for now this will not be important. The patch also includes a modification to readelf so that it will display the OPTIONAL flag if it is defined in an Irix binary. You do not actually need this part of the patch in order to get a working linker, but I have included it since it is all part of the same problem. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/1150] undefined reference to `_mpi_sgi_init'
Hi Michael, The testcase nwo runs fine with the patched ld: Great - I will check that patch in then as a first step in resolving this PR. But the original problem with libpthread remains: [EMAIL PROTECTED] ~]$ gcc -o t t.o -lpthread /usr/lib/../lib64/libpthread.so: undefined reference to `_mpi_sgi_init' Ho Hum. Is there a difference in treatment of object and *shared* object symbols? Yes - they can be handled differently, and presumably they are being treated differently in this case. Can you investigate this part of the problem ? Basically you need to find where this undefined symbol is being detected. It will almost certainly be just before some code that calls: link_info->callbacks->undefined_symbol somewhere in the BFD library code. Alternatively if you make those Irix system files available to me, I can have a go - BUT ... I am about to go off and work at a client site for a month or so, so I will not be able to put as much time into binutils work. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/1150] undefined reference to `_mpi_sgi_init'
Hi Michael, using the above test case I tracked down the place in elflink.c where the symbol os is reported as undefined when localed in a shared library. The attached patch hacks elflink.c to check for STO_OPTIONAL in h->other. This makes the test case work with both native IRIX and Mac OS X cross binutils: Excellent! I am a little bit hesitant to apply your patch as it is however since it adds target specific code to a file that is meant to be generic. Could you investigate changing your patch so that it adds a new elf backend function which can be called when an undefined symbol is encountered and which allows individual backends to decide if the symbol can be ignored ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/1150] undefined reference to `_mpi_sgi_init'
Hi Rainer, Did somebody else some tests using these binutils patches? Not yet, but I am back at my normal workplace now, so this is on my list. Is there a chance that these patches will be applied? Yup, in a couple of days probably. Sorry for the delay. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: FW: Problem with gnu-ld
Hi JAIN, [EMAIL PROTECTED] ld-bug]$ ld --version GNU ld version 2.14.90.0.4 20030523 This is an old release of the linker. Please try the latest release (2.16) or, even better, the current development sources. This may well fix the problem. If it still fails, please could you post the linker script (with the MEMORY regions) to this list so that we can look at it. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Bug in relocation name table
Hi Alexis, The following table (in version 2.14 to 2.16 at least) includes relocation names. The last name "HIGH3ADJ" is concatenated with the word "UNKNOWN" since the person who wrote the table missed one comma. Thanks for pointing this out. I have checked in the correction along with this ChangeLog entry. Cheers Nick bfd/ChangeLog 2006-01-09 Alexis Wilke <[EMAIL PROTECTED]> * peXXigen.c (tbl): Add comma after "HIGH3ADJ". ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: How to overcome the problem created when binutils is installed?
Hi Ashwani, i have fedora core 3 distribution with gcc version 4.0 .When i installed binutils 2.13 2.13 is a very old release. You really should be using the 2.16 release, which you ought to have found included with the gcc 4.0 distribution that you are using. each and every program when compiled gave an error Collect2 : ld 1 exit status (something like that) . I removed the libraries ( e.g libiberty.a ,etc) from the directory of /usr/lib .But the problem remained. Can anybody tell me what happens to the loader after the bintuils is installed and how to overcome it ? Neither collect2 nor ld is a loader. The former is a wrapper program which invokes the latter. ld is a linker. If you still have the problem after switching over to the 2.16 binutils release then may I suggest adding the --verbose switch to the linker command line ? (presumably via adding -Wl,--verbose to your gcc command line). This may help you track down where in the linker the problem is occurring. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/1391] objcopy trashes PE executable when using "add-gnu-debuglink"
Hi Brian, PR binutils/1391 * objcopy.c (copy_object): For PE format targets set the VMA of a newly created gnu_debuglink section to a non-zero, aligned, contiguous value. * Makefile.am (objcopy.c): Add a dependency upon libbfd.h. * Makefile.in: Regenerate. Sorry. I was waiting to reply until I had a chance to test it, and time has been in short supply lately. Two questions though: Pedantically, doesn't this patch belong in bfd/opncls.c (bfd_create_gnu_debuglink_section)? Actually I think not. That function just creates the debuglink section, in much the same way as the bfd_make_section() function just creates a normal section. It is up to other code to decide what to do with these created sections. Objcopy decides to insert it into the binary file it is creating, therefore it is objcopy's responsibility to select a VMA for it. Another user of the bfd_create_gnu_debuglink_section() might decide to do something else with it, and may not even include it in an output file. What was the other question ? :-) Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: help
Hi Zhao, When I use arm-elf-readelf , I have one question. Can you output one section all info . I want display all [ 17 ] bss section all information. as bellow. 29284: 11f56d88 200 OBJECT GLOBAL DEFAULT 17 GetGSMCmdBuf 29296: 11e02340 4 OBJECT GLOBAL DEFAULT 17 listfontp Sorry no. Or at least not with the current sources. You could always add this feature if you wanted to. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: objcopy --add-section doubt
Hi Kartikeyan, With binutils that come with RH9 version binutils-2.13.90.0.18-9 (rpm) I am able to add any arbitary file(i am trying a text file) as a ELF section eg:- objcopy --add-section .skdata= Everything works as expected When I try with binutils version binutils-2.15.94.0.2.2-2 (FC4 rpm) I get the following error (I am trying add a text file ) objcopy: can't create section `.skdata': File in wrong format Hmm, it should work with the newer version of binutils. Can you try using the latest binutils release (2.16) or, even better, the current binutils sources in the CVS repository ? If the problem still exists, please could you post a small example of how to reproduce the problem so that we can investigate further ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: objcopy --add-section doubt
Hi Kartikeyan,
Thanks for the test case. Using it I was able to reproduce the problem.
so NULL is being returned as newsect->name is not NULL
Yes - this is the heart of the matter. What is happening is that you
are attempting to add a section that already exists. The old (RH9)
binutils silently allowed this, which was incorrect. The current
binutils sources does not allow the existing section to be re-added, but
it does produce a very unhelpful warning message.
The attached patch (which I will be checking into the sources shortly)
changes the warning to:
can't add section '.skdata' - it already exists!
which I think is much better.
I AM NOT A EXPERT IN BINUTILS.
It's OK there is no need to shout.
If you want to achieve the old behaviour of RH9 then you can just amend
your objcopy command line to include "--remove-section .skdata" before
the "--add-section .skdata=a" switch.
Cheers
Nick
binutils/ChangeLog
2006-01-30 Nick Clifton <[EMAIL PROTECTED]>
* objcopy.c (copy_object): Catch the case where an attempt is made
to add a section that already exists and produce a more helpful
warning message.
Index: binutils/objcopy.c
===
RCS file: /cvs/src/src/binutils/objcopy.c,v
retrieving revision 1.93
diff -c -3 -p -r1.93 objcopy.c
*** binutils/objcopy.c 18 Jan 2006 11:01:09 - 1.93
--- binutils/objcopy.c 30 Jan 2006 12:58:45 -
*** copy_object (bfd *ibfd, bfd *obfd)
*** 1313,1325
if (pset != NULL && pset->set_flags)
flags = pset->flags | SEC_HAS_CONTENTS;
! padd->section = bfd_make_section_with_flags (obfd, padd->name, flags);
! if (padd->section == NULL)
{
! non_fatal (_("can't create section `%s': %s"),
! padd->name, bfd_errmsg (bfd_get_error ()));
return FALSE;
}
if (! bfd_set_section_size (obfd, padd->section, padd->size))
{
--- 1313,1335
if (pset != NULL && pset->set_flags)
flags = pset->flags | SEC_HAS_CONTENTS;
! /* bfd_make_section_with_flags() does not return very helpful
! error codes, so check for the most likely user error first. */
! if (bfd_get_section_by_name (obfd, padd->name))
{
! non_fatal (_("can't add section '%s' - it already exists!"), padd->name);
return FALSE;
}
+ else
+ {
+ padd->section = bfd_make_section_with_flags (obfd, padd->name, flags);
+ if (padd->section == NULL)
+ {
+ non_fatal (_("can't create section `%s': %s"),
+ padd->name, bfd_errmsg (bfd_get_error ()));
+ return FALSE;
+ }
+ }
if (! bfd_set_section_size (obfd, padd->section, padd->size))
{
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Building binutils-2.15.97 --enable-targets=all
Hi Muhammad, While building binutils (binutils-2.15.97.tar.bz2) on Cygwin, as follows: configure --enable-targets=all --enable-shared --with-gnu-as --with-gnu-ld make I got the following error: obj-coff.o: In function `coff_frob_symbol': /usr/src/binutils-2.15.97/gas/config/obj-coff.c:1145: undefined reference to `_an_external_name' This does not happen with the latest sources in the CVS repository, nor with the officially released 2.16 sources, so I do not really see this as a problem. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: objcopy --add-section doubt
Hi Daniel, Yes - this is the heart of the matter. What is happening is that you are attempting to add a section that already exists. The old (RH9) binutils silently allowed this, which was incorrect. Wait... why? There's no restriction in ELF about having multiple sections with the same name; some non-GNU tools do this a lot. Err, good point. I suppose that technically it is allowed. I guess that means that we need a new section creator function, one that does not refuse to create a section when another one of the same name already exists. Hmm, this might get messy... I'll think about it. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Assembler unable to handle relative offsets in PIC code under cross-compiling env.
Hi Ayonam, The assembly fragment in question looks like this: .section.rodata .L5465: .long .L5457-.+(.-.L5465) .long .L5458-.+(.-.L5465) <<- Problem first reported here .section .gnu.linkonce.t._ZNK6Layout12StdTransformIiE9transformIdEEKNS_5PointIT_EERS6_ .L5458: The problem is that the two symbols (.L5458 and .L5465) are in different sections. Therefore it is impossible for the assembler to calculate the distance between them. Since the symbols are local symbols they are not emitted into the object file and so they are not available for the linker to calculate the distance either. The real root of the problem I believe is that you are using a broken compiler. You say that you are using GCC 2.3.2 which is an extremely old version. I would strongly urge you to upgrade to the 2.95 release, or better yet the 3.4.4 release or even the 4.1 release. If you cannot do this then see if the version of gcc you are using has any switches to alter the way it handles case statements. eg -fno-jump-tables. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Assembler unable to handle relative offsets in PIC code under cross-compiling env.
Hi Ayonam, I'm using gcc version 3.2.2 and I think I also gave a try with 3.4.3 also. I'll verify this and get back to you. It would also be very good to know if this is a problem with the current GCC sources in the mainline of the FSF repository. ie is this a bug in GCC that has already been fixed ? (Or more likely it is a limitation in GAS which has been fixed in GCC by having it not generate the type of expressions that causes GAS to choke). Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: -al
Hi George, I have been using the -al=file to generate assembler listing files. In version 2.16 this is being interpreted as --alternate. I am unable to reproduce this problem, either using the 2.16 branch sources or the current CVS mainline sources. For example: % arm-elf-gas -al nop.s -o nop.o ARM GAS nop.s page 1 1.text 2.global fred 3fred: 4 A0E1 nop 5 Can you provide more details about how you encountered this problem ? Do you have a test case that reproduces it ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Problem using -X and -N together with gnutar?
Hi Robert, tar (GNU tar) 1.14 Sorry - you have the wrong mailing list. This is the list for bug reports concerning the GNU Binary Utilities (binutils). You want the GNU Tar bug list which is: bug-tar@gnu.org Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: -al
Hi George,
I have been using the -al=file to generate assembler listing files. In
version 2.16 this is being interpreted as --alternate.
Oops - sorry - please ignore my previous post. I missed that you were
using the '=file' syntax. When I added that to the command line of my
2.16 test build I was able to reproduce your problem.
Please could you try the attached patch. I believe that it will resolve
the problem.
Cheers
Nick
gas/ChangeLog
2006-03-08 Nick Clifton <[EMAIL PROTECTED]>
* as.c (parse_args): Add an entry for "al" to prevent -al from
being confused with --alternate.
Index: gas/as.c
===
RCS file: /cvs/src/src/gas/as.c,v
retrieving revision 1.58
diff -c -3 -p -r1.58 as.c
*** gas/as.c 3 Mar 2005 01:29:52 - 1.58
--- gas/as.c 8 Mar 2006 10:06:32 -
*** parse_args (int * pargc, char *** pargv)
*** 437,447
the end of the preceeding line so that it is simpler to
selectively add and remove lines from this list. */
{"alternate", no_argument, NULL, OPTION_ALTERNATE}
! /* The entry for "a" is here to prevent getopt_long_only() from
!considering that -a is an abbreviation for --alternate. This is
!necessary because -a= is a valid switch but getopt would
!normally reject it since --alternate does not take an argument. */
,{"a", optional_argument, NULL, 'a'}
,{"defsym", required_argument, NULL, OPTION_DEFSYM}
,{"dump-config", no_argument, NULL, OPTION_DUMPCONFIG}
,{"emulation", required_argument, NULL, OPTION_EMULATION}
--- 437,448
the end of the preceeding line so that it is simpler to
selectively add and remove lines from this list. */
{"alternate", no_argument, NULL, OPTION_ALTERNATE}
! /* The next two entries are here to prevent getopt_long_only() from
!considering that -a or -al is an abbreviation for --alternate.
!This is necessary because -a= is a valid switch but getopt
!would normally reject it since --alternate does not take an argument. */
,{"a", optional_argument, NULL, 'a'}
+ ,{"al", optional_argument, NULL, 'a'}
,{"defsym", required_argument, NULL, OPTION_DEFSYM}
,{"dump-config", no_argument, NULL, OPTION_DUMPCONFIG}
,{"emulation", required_argument, NULL, OPTION_EMULATION}
*** main (int argc, char ** argv)
*** 1205,1211
keep_it = 0;
if (!keep_it)
! unlink_if_ordinary (out_file_name);
input_scrub_end ();
--- 1206,1212
keep_it = 0;
if (!keep_it)
! unlink (out_file_name);
input_scrub_end ();
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/2378] Incorrect opcode in __do_clear_bss if bss has more than 15 bytes
Hi Ken, avr-as a.S -o a.o avr-ld -m avr4 -Tdata 0x800100 -o a.elf a.o avr-objdump -d a.elf > a.lst avr-ld -m avr4 -Tdata 0x800100 -o a.hex --oformat=ihex a.o The list file shows both opcodes correctly, "a0 31". But in the hex file the first one is wrong, "B031", while the second one is correct, "A031". The difference is that avr-ld had to do a relocation for the first one. Running "avr-objdump -r a.o" shows one record with type R_AVR_LO8_LDI relocation, value __bss_end. R_AVR_LO8_LDI is performed in binutils-2.16.1/bfd/elf32-avr.c. It works correctly for the default ELF format, but fails for the IHEX format. This is progress, but I'm still stumped. It is quite common that LD is unable to correctly translate binary file formats and link at the same time. Quite a few targets suffer from this problem. The simplest workaround is to perform the link first and then use objcopy to perform the binary translation. ie: avr-ld -m avr4 -Tdata 0x800100 -o a.elf a.o avr-objcopy --output-target ihex a.elf a.ihex Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: -al
Hi Daniel, *** main (int argc, char ** argv) *** 1205,1211 keep_it = 0; if (!keep_it) ! unlink_if_ordinary (out_file_name); input_scrub_end (); --- 1206,1212 keep_it = 0; if (!keep_it) ! unlink (out_file_name); input_scrub_end (); Is this bit unrelated? Doh! Yes, that was because I had been trying to use the 2.16 sources with a libiberty from various different gcc branches (4.0 or 3.4 or some such earlier gcc). The libiberty libraries in these earlier gcc source trees do not have the unlink_if_ordinary() function, and rather than upgrade all of them, or change my symbolic link tree to use the libiberty in 2.16 binutils (which would cause its own problems), I chose to *locally* modify the 2.16 sources. It is not my intention to check this change into the actual 2.16 branch, and if I had been paying more attention I would have edited it out of the patch before posting it. Sorry. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/2454] New: incorrect syntax in avr disassembly
Hi hochstein, The disassembly for call and jmp looks like this: 43a: 0e 94 7e 0e call0x1cfc <__divmodhi4> This causes problems since the "" part is not correct assembler syntax. It should read like this: 43a: 0e 94 7e 0e call0x1cfc ; <__divmodhi4> Do you have a *small* test case to reproduce this behaviour ? Also - have you tried the current sources in the mainline binutils CVS repository ? I think that they may already have the desired behaviour. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gprof
Hi Susukita, $ time ./a.out real0m4.324s $ gprof a.out Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 9.46 43.22 4.09 rand This looks like a gprof bug. Specifically I would guess that either the sample period is incorrect or else the clock frequency calculated by the gprof/hertz.c:hertz() function is wrong. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: objdump
Hi Paz, My name is paz and I have a doubt, how can I convert my ".srec" file to ".od" to use it with AVRORA?? Sorry, but I do not think the objcopy supports the Avrora .od file format, so you cannot do this using the binutils. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/2582] New: dwarf2dbg.c embeds absolute filename path with hard-coded / separator
Hi Burgess, dwarf2dbg.c -- line 1476 of CVS version 1.81: p[len] = '/'; This inserts a filesystem separator character when tacking the source filename back onto the source directory when providing the source-file's path for DWARF2 debugging information. HOWEVER in Windows systems where the filename has been specified in Windows format, i.e. C:\Workspaces\Eclipse \Blinky\init.s, this creates a filename in the DWARF2 debugging information that looks like C: \Workspaces\Eclipse\Blinky/init.s -- and boy does that confuse ARM's Realview debugger for my ARM- based embedded system. OK - so here is a patch for you to try out. (Well uploaded to the PR). One thing I am particularly worried about is the heuristic I am using to decide when to use the \ directory separator. At the moment it looks for paths starting with a drive letter eg C:. Are there situations where there can be paths without this drive letter which still need the backslash separator ? Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gprof/2587] New: Failed to build gprof under gmake patched by Apple.
Hi Masaki, Building gprof was failed because of patched gmake (bundled with OSX). Follow is a patch to disable a builtin suffix rule. diststuff: $(BUILT_SOURCES) info $(man_MANS) +# this empry rule is a hack against gmake patched by Apple. +%.o:%.m + .m.c: awk -f $(srcdir)/gen-c-prog.awk > ./$*.c ? FUNCTION=`(echo $*|sed -e 's,.*/,,g' -e 's/_bl//')`_blurb ? I have applied this patch, although obviously we hope that Apple will fix their version of gmake as well. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/2582] dwarf2dbg.c embeds absolute filename path with hard-coded / separator
Hi Bill, Another thought -- why not look for the THIRD character to be a backslash? This will handle not only absolute paths that start with :\ but also relative paths that start with ..\ -- what do you think? --Bill That wouldn't work. Not all relative paths start with "..". For example if the file is in a sub-directory of the build directory then the path might just be "/". In addition it is possible that the backslash character might be there to escape an unconventional path name character. For example suppose that (in a UNIX style naming convention) the root directory contains a sub-directory called "A Directory", and the code wants to reference a file called "Foo" inside this directory. This would appear as /A\ Directory/Foo Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/2582] dwarf2dbg.c embeds absolute filename path with hard-coded / separator
Hi Bill, My dev system is back up but I find I am too much of a noob to build the binutils so I can test the patch. I'm unfamiliar with building GNU tools in any environment, to say nothing of Windows and cygwin which I avoid like the plague, and lost heart when my first attempt produced dozens of unresolved dependencies. Meanwhile other time pressures have increased so I'll have to stay a GNU- noob. Oh well, In which case I shall assume that the patch works and check it in to the sources. If you ever come across this problem again, feel free to reopen the problem report. Cheers Nick PS. Committed with this ChangeLog entry: gas/ChangeLog 2006-05-05 Nick Clifton <[EMAIL PROTECTED]> PR gas/2582 * dwarf2dbg.c (INSERT_DIR_SEPARATOR): New macro. Handles the insertion of a directory separator character into a string at a given offset. Uses heuristics to decide when to use a backslash character rather than a forward-slash character. (dwarf2_directive_loc): Use the macro. (out_debug_info): Likewise. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
