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: what about new feature for objcopy
Hi Nick, 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. It's impossible to debug and profile that functions. As you know, there are only object-members so far :( And therefore there is no another way for correction. As for patch, unfortunately I have no enough time to select good option names, interface and so. But implementation, I am sure is very simple. So, I'd like to get your proposals before. Thanks in advance. Regards, Victor On Thu, 04 Aug 2005 08:35:11 +0100 Nick Clifton <[EMAIL PROTECTED]> wrote: 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 --- http://auto.ngs.ru - в продаже более 1200 авто ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
binutils 2.16.1 assembler dwarf2 relocations break solaris native ld
All of the following is on Solaris 9 SPARC, using binutils-2.16.1. These are the entire contents of os_SunOS.s from NSPR 4.6.0: /* * sol_getsp() * * Return the current sp (for debugging) */ .global sol_getsp sol_getsp: retl mov %sp, %o0 /* * sol_curthread() * * Return a unique identifier for the currently active thread. */ .global sol_curthread sol_curthread: retl mov %g7, %o0 .global __MD_FlushRegisterWindows .global _MD_FlushRegisterWindows __MD_FlushRegisterWindows: _MD_FlushRegisterWindows: ta 3 ret restore When driving the binutils-2.16.1 assembler through gcc-4.0.1 with /usr/local/gcc-4.0.1/bin/gcc -g -fPIC file.s -c -o file.o gcc plans to invoke gas as follows: "/usr/local/binutils-2.16.1/bin/as" "--gdwarf2" "--traditional-format" "-Qy" "-s" "-K" "PIC" "-xarch=v8" "-o" "file.o" "file.s" In the generated object file relocations for the debug info are marked as R_SPARC_32: Relocation section '.rela.debug_line' at offset 0x4cc contains 1 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0027 0103 R_SPARC_32 .text + 0 Relocation section '.rela.debug_info' at offset 0x4d8 contains 4 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0006 0503 R_SPARC_32 .debug_abbrev + 0 000c 0603 R_SPARC_32 .debug_line + 0 0010 0103 R_SPARC_32 .text + 0 0014 0103 R_SPARC_32 .text + 1c Relocation section '.rela.debug_aranges' at offset 0x508 contains 2 entries: Offset InfoTypeSym.Value Sym. Name + Addend 0006 0403 R_SPARC_32 .debug_info + 0 0010 0103 R_SPARC_32 .text + 0 The binutils linker is fine building a shared library from this object file: /usr/local/binutils-2.16.1/bin/ld -shared file.o -o file.so but trying to link this into a shared library with the solaris native ld does not go well at all: /usr/ccs/bin/ld -G file.o -o file.so ld: fatal: relocation error: R_SPARC_32: file file.o: symbol : offset 0xff1904ef is non-aligned ld: fatal: relocation error: R_SPARC_32: file file.o: symbol : offset 0xff190509 is non-aligned ld: fatal: relocation error: R_SPARC_32: file file.o: symbol : offset 0xff19050f is non-aligned ld: fatal: relocation error: R_SPARC_32: file file.o: symbol : offset 0xff190513 is non-aligned ld: fatal: relocation error: R_SPARC_32: file file.o: symbol : offset 0xff190517 is non-aligned ld: fatal: relocation error: R_SPARC_32: file file.o: symbol : offset 0xff19057e is non-aligned If I re-run the assembly step with any of -gstabs, -gstabs+ or no debugging selected at all, the solaris linker is fine, so this seems to be specific to --gdwarf2. So who is right here? Is there really an alignment problem with the debug sections in the object file, or is the solaris linker just confused? If there is a problem, why doesn't binutils ld complain? Any ideas? Thanks, Andrew ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
issue with -R option coupled with -Xlinker gcc option
Hi, Tool detail: Arm-elf-gcc version : 4.0.0 Arm-elf-ld version : 2.15 This issue is to do with the R linker option. Usually with other tool-chains you provide the symbol file to the link step to link a different image in a separate memory region. But, in case of gcc (mipsisa32-elf-gcc) I supply the elf output of one image to the link step of 2nd image with the R linker option & it worked. I tried the same with ARM architecture (arm-elf-gcc) & provided the R option to gcc coupled with the Xlinker option & it produces the following error: arm-elf-gcc ramcode.o frmwrk.o consol.o led.o rtc.o stke.o ac_armdefs.o ac_halt. o init.o -mcpu=arm7tdmi -nostartfiles -T ./../../../../config/gcc/link2106_ram .ld -Wl,-Map=symfiletest_ram.map,--cref -o symfiletest_ram.elf -Xlinker -R -Xlin ker ./../../rom/bin/romlib_ram.elf /opt/gnuarm/bin/../lib/gcc/arm-elf/4.0.0/../../../../arm-elf/bin/ld: internal er ror: aborting at ../../binutils-2.15/ld/ldlang.c line 3835 in lang_place_orphans /opt/gnuarm/bin/../lib/gcc/arm-elf/4.0.0/../../../../arm-elf/bin/ld: please repo rt this bug collect2: ld returned 1 exit status make: *** [symfiletest_ram.elf] Error 1 Please help me with this issue!! Thanks, -Mike. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
