Possible bug - GAS for RSIC-V
Greetings, Assembly code below prints a Hello message on stdout under Linux. It is a simple call to Write system call while the address of my_str is loaded and passed via ABI conventions. *However, if you uncomment the second line, we will face an issue and no prints happen. Can we review this:* cat > main.s .data *#my_var1: .int 1 #* my_str: .asciz "Hello\n" .text .global _start print: addi sp, sp, -40 sd ra, 0(sp) sd a0, 8(sp) sd a1, 16(sp) sd a2, 24(sp) sd a7, 32(sp) li a0, 1 la a1, my_str li a2, 6 li a7, 64 ecall ld ra, 0(sp) ld a0, 8(sp) ld a1, 16(sp) ld a2, 24(sp) ld a7, 32(sp) addi sp, sp, 40 ret _start: call print li a0, 0 li a7, 93 ecall [root@fedora-riscv ~]# as -o main.o main.s; ld -o main main.o; ./main Hello *If you uncomment the second line (my_var1: .int 1), the program will no longer print anything!!!*: [root@fedora-riscv ~]# rm -f main.o main [root@fedora-riscv ~]# as -o main.o main.s; ld -o main main.o; ./main [root@fedora-riscv ~]# ## Please note, all we did was just to use .int directive in the data section and very oddly we no longer can access my_str ... I tried to use .align 3 to make sure we have 64 bit alignment with no luck ... ## [root@fedora-riscv ~]# as --version GNU assembler version 2.39-4.fc37 Copyright (C) 2022 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `riscv64-redhat-linux'. [root@fedora-riscv ~]# cat /proc/cpuinfo processor : 0 hart : 5 isa : rv64imafdch_sstc_zicbom_zihintpause mmu : sv57 processor : 1 hart : 0 isa : rv64imafdch_sstc_zicbom_zihintpause mmu : sv57 processor : 2 hart : 1 isa : rv64imafdch_sstc_zicbom_zihintpause mmu : sv57 processor : 3 hart : 2 isa : rv64imafdch_sstc_zicbom_zihintpause mmu : sv57 processor : 4 hart : 3 isa : rv64imafdch_sstc_zicbom_zihintpause mmu : sv57 processor : 5 hart : 4 isa : rv64imafdch_sstc_zicbom_zihintpause mmu : sv57 [root@fedora-riscv ~]# uname -a Linux fedora-riscv 6.0.10-300.0.riscv64.fc37.riscv64 #1 SMP Sun Nov 27 19:08:44 GMT 2022 riscv64 riscv64 riscv64 GNU/Linux System is vanilla Fedora 37 running under the QEMU emulator version 8.0.2 for RISC-V 64. Thank you, David
Run objdump under windows XP for XCOFF object file created from IBM AIX system
Hi, I need to run objdump under windows XP to dump out XCOFF format object files created from IBM AIX environment, is that possible? I went to gnu.org site, and do not see where I can download the gnu package containing the objdump command, anybody could help me with this? Thanks David ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system
Hi, Ian, thanks for your response, I already downloaded both cygwin and binutils, I used objdump of cygwin to dump out ELF format object files for my current project under windows XP, now my project needs to support XCOFF object file dumping in XP environment, the binutils I downloaded seems not for windows XP environment when I looked at the files I untarred, is there any MS windows version of binutils? how can I build my own version of the binutils for rs6000-aix target? I checked the binutils source code, it seems supporting rs6000-aix target already. Thanks for further pointing direction for me David -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Monday, March 07, 2005 9:48 PM To: David Du Cc: bug-binutils@gnu.org Subject: Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system "David Du" <[EMAIL PROTECTED]> writes: > Hi, I need to run objdump under windows XP to dump out XCOFF format object > files > created from IBM AIX environment, is that possible? I went to gnu.org site, > and do not see where I can download the gnu package containing the objdump > command, anybody could help me with this? Yes, it is possible, but it is not particularly easy if you are not familiar with this kind of thing. If you have not done so already, you will need to download cygwin--see http://cygwin.com/ That will give you an objdump, but one that only supports PE COFF. You will need to build your own version of the binutils for the rs6000-aix target. You can do this using cygwin. Download the binutils sources from, and follow the directions. http://sourceware.org/binutils/ Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Run objdump under windows XP for XCOFF object file created from IBM AIX system
Hi, I need to run objdump under windows XP to dump out XCOFF format object files created from IBM AIX environment, is that possible? I went to gnu.org site, and do not see where I can download the gnu package containing the objdump command, anybody could help me with this? Thanks David ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system
Hi, Ian, thanks for your response again, I checked the binutils/README, it talks about how to build for unix-like system, not for windows XP environment, for example, it asks to do ./configure command, which in the binutils directory is not a DOS or windows command, when I run the commands, they just did not work, the version of binutils I downloaded is binutils-2.15, I am not sure what I should do. Would you please help me with this issue again? Thanks David -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Monday, March 07, 2005 11:13 PM To: David Du Cc: bug-binutils@gnu.org Subject: Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system "David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, thanks for your response, I already downloaded both cygwin and > binutils, I used objdump of cygwin to dump out ELF format object files for > my current project under windows XP, now my project needs to support XCOFF > object file dumping in XP environment, the binutils I downloaded seems not > for windows XP environment when I looked at the files I untarred, is there > any MS windows version of binutils? how can I build my own version of the > binutils for rs6000-aix target? I checked the binutils source code, it seems > supporting rs6000-aix target already. In the binutils source code see binutils/README for how to build. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system
Hi, Ian, I got what you mean with cygwin, I just built the binutils with the help of cygwin, but unfortunately the objdump.exe command donot support xcoff format when I run objdump -i, it will list all the supported format, I checked the objdump.c source code, it never has any information about xcoff, but in other source code like xcoff.h, it has some xcoff information, I donot know what I need to configure to support xcoff format. any idea? Thanks David -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 10:32 AM To: David Du Cc: bug-binutils@gnu.org Subject: Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system "David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, thanks for your response again, I checked the binutils/README, it > talks about how to build for unix-like system, not for windows XP > environment, for example, it asks to do ./configure command, which in the > binutils directory is not a DOS or windows command, when I run the commands, > they just did not work, the version of binutils I downloaded is > binutils-2.15, I am not sure what I should do. Would you please help me with > this issue again? Downloading cygwin from http://cygwin.com/ will give you a Unix-like environment on Windows. It is sufficient to build the binutils. You should run configure from the cygwin shell. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system
Hi, Ian, thanks again for your help, I tried to configure with --target=rs6000-ibm-aix, and built the binutils, when I tested the objdump.exe file with objdump -i, it gave me error: "objdump: can't set BFD default target to 'rs6000-ibm-aix': Invalid bfd target", I tried to configure with --target=rs6000-aix as described in readme, it gave me the same error message, after that I tried to configure with --enable-targets=all, then tested with objdump -i, it gave me all the supported things like pe-i386, elf32-i386 etc, but no rs6000-aix, any idea or what have I done wrong? Thanks for your kind help! David -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 12:20 PM To: David Du Cc: bug-binutils@gnu.org Subject: Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system "David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, I got what you mean with cygwin, I just built the binutils with the > help of cygwin, but unfortunately the objdump.exe command donot support > xcoff format when I run objdump -i, it will list all the supported format, I > checked the objdump.c source code, it never has any information about xcoff, > but in other source code like xcoff.h, it has some xcoff information, I > donot know what I need to configure to support xcoff format. any idea? configure with --target rs6000-ibm-aix Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system
Hi, Ian, I tried both powerpc-aix and powerpc-elf, when I tested objdump -i, they gave me error saying "objdump: can't set BFD default target to powerpc-aix: Invalid bfd target" and "objdump: can't set BFD default target to powerpc-unknown-elf: Invalid bfd target"; any other idea? Thanks David -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 1:38 PM To: David Du Cc: bug-binutils@gnu.org Subject: Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system "David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, thanks again for your help, I tried to configure > with --target=rs6000-ibm-aix, and built the binutils, when I tested the > objdump.exe file with objdump -i, it gave me error: "objdump: can't set BFD > default target to 'rs6000-ibm-aix': Invalid bfd target", I tried to > configure with --target=rs6000-aix as described in readme, it gave me the > same error message, after that I tried to configure > with --enable-targets=all, then tested with objdump -i, it gave me all the > supported things like pe-i386, elf32-i386 etc, but no rs6000-aix, any idea > or what have I done wrong? Hmmm, maybe you need --target=powerpc-aix these days. Or even --target=powerpc-elf should give you an objdump which can read XCOFF files. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system
Ok Ian, thank you anyway. David -Original Message- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 08, 2005 3:02 PM To: David Du Cc: bug-binutils@gnu.org Subject: Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system "David Du" <[EMAIL PROTECTED]> writes: > Hi, Ian, I tried both powerpc-aix and powerpc-elf, when I tested objdump -i, > they gave me error saying "objdump: can't set BFD default target to > powerpc-aix: Invalid bfd target" and "objdump: can't set BFD default target > to powerpc-unknown-elf: Invalid bfd target"; any other idea? No, I don't know offhand what is going on there. Sorry. Ian ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system
HI, Ben, thanks for your response, I checked and redid my testing, I used the right objdump.exe file, after I did make all and built the binutil, all the exe files are under the binutils directory, so I just ran the objdump.exe file under that directory, ./objdump -i, and also I tried and changed the objdump.exe of cygwin to objdump1.exe, and the objdump.exe under binutils directory to objdump2.exe, ran each of them, here is the results: And also I configured the target to just rs6000-aix, and build the binutils and then ran make install, they then were installed under cygwin/usr/local/bin directory, called rs6000-aix-objdump.exe, after I ran this file, it said invalid target as shown in the following: Any other idea what is wrong? THanks for your help. David This is from cygwin: C:\>which objdump1 /usr/bin/objdump1 C:\>objdump1 -i BFD header file version 2.15.91 20040725 pe-i386 (header little endian, data little endian) i386 pei-i386 (header little endian, data little endian) i386 elf32-i386 (header little endian, data little endian) i386 elf32-little (header little endian, data little endian) i386 elf32-big (header big endian, data big endian) i386 srec (header endianness unknown, data endianness unknown) i386 symbolsrec (header endianness unknown, data endianness unknown) i386 tekhex (header endianness unknown, data endianness unknown) i386 binary (header endianness unknown, data endianness unknown) i386 ihex (header endianness unknown, data endianness unknown) i386 pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec i386 pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex i386 symbolsrec tekhex binary ihex THis one is from binutils, I rename it to objdump2: $ pwd /cygdrive/c/gnu/binutils-2.15/binutils $ which objdump2 ./objdump2 $ objdump2 -i BFD header file version 2.15 pe-i386 (header little endian, data little endian) i386 pei-i386 (header little endian, data little endian) i386 elf32-i386 (header little endian, data little endian) i386 elf32-little (header little endian, data little endian) i386 elf32-big (header big endian, data big endian) i386 srec (header endianness unknown, data endianness unknown) i386 symbolsrec (header endianness unknown, data endianness unknown) i386 tekhex (header endianness unknown, data endianness unknown) i386 binary (header endianness unknown, data endianness unknown) i386 ihex (header endianness unknown, data endianness unknown) i386 pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec i386 pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex i386 symbolsrec tekhex binary ihex THis one is after I configure target to rs6000-aix and ran make install: C:\cygwin\usr\local\bin>rs6000-aix-objdump -i rs6000-aix-objdump: can't set BFD default target to `rs6000-ibm-aix': Invalid bfd target -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ben Elliston Sent: Tuesday, March 08, 2005 10:08 PM To: bug-binutils@gnu.org Subject: Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system David Du wrote: > Hi, Ian, I tried both powerpc-aix and powerpc-elf, when I tested objdump -i, > they gave me error saying "objdump: can't set BFD default target to > powerpc-aix: Invalid bfd target" and "objdump: can't set BFD default target > to powerpc-unknown-elf: Invalid bfd target"; any other idea? At the risk of being the next bunny to answer a spate of newbie questions .. David, it sounds like you aren't running the right objdump. You may have one installed with Cygwin already. When you build binutils, where are you installing it with `make install'? Are you sure that when you run `objdump', it's the one you're expecting? Try `which objdump' to be sure. Ben ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system
Hi, anybody can answer this question: objdump not working for IBM AIX xcoff object file? Thanks David -Original Message- From: David Du [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 9:52 AM To: Ben Elliston; bug-binutils@gnu.org Subject: RE: Run objdump under windows XP for XCOFF object file created from IBM AIX system HI, Ben, thanks for your response, I checked and redid my testing, I used the right objdump.exe file, after I did make all and built the binutil, all the exe files are under the binutils directory, so I just ran the objdump.exe file under that directory, ./objdump -i, and also I tried and changed the objdump.exe of cygwin to objdump1.exe, and the objdump.exe under binutils directory to objdump2.exe, ran each of them, here is the results: And also I configured the target to just rs6000-aix, and build the binutils and then ran make install, they then were installed under cygwin/usr/local/bin directory, called rs6000-aix-objdump.exe, after I ran this file, it said invalid target as shown in the following: Any other idea what is wrong? THanks for your help. David This is from cygwin: C:\>which objdump1 /usr/bin/objdump1 C:\>objdump1 -i BFD header file version 2.15.91 20040725 pe-i386 (header little endian, data little endian) i386 pei-i386 (header little endian, data little endian) i386 elf32-i386 (header little endian, data little endian) i386 elf32-little (header little endian, data little endian) i386 elf32-big (header big endian, data big endian) i386 srec (header endianness unknown, data endianness unknown) i386 symbolsrec (header endianness unknown, data endianness unknown) i386 tekhex (header endianness unknown, data endianness unknown) i386 binary (header endianness unknown, data endianness unknown) i386 ihex (header endianness unknown, data endianness unknown) i386 pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec i386 pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex i386 symbolsrec tekhex binary ihex THis one is from binutils, I rename it to objdump2: $ pwd /cygdrive/c/gnu/binutils-2.15/binutils $ which objdump2 ./objdump2 $ objdump2 -i BFD header file version 2.15 pe-i386 (header little endian, data little endian) i386 pei-i386 (header little endian, data little endian) i386 elf32-i386 (header little endian, data little endian) i386 elf32-little (header little endian, data little endian) i386 elf32-big (header big endian, data big endian) i386 srec (header endianness unknown, data endianness unknown) i386 symbolsrec (header endianness unknown, data endianness unknown) i386 tekhex (header endianness unknown, data endianness unknown) i386 binary (header endianness unknown, data endianness unknown) i386 ihex (header endianness unknown, data endianness unknown) i386 pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec i386 pe-i386 pei-i386 elf32-i386 elf32-little elf32-big srec symbolsrec tekhex binary ihex i386 symbolsrec tekhex binary ihex THis one is after I configure target to rs6000-aix and ran make install: C:\cygwin\usr\local\bin>rs6000-aix-objdump -i rs6000-aix-objdump: can't set BFD default target to `rs6000-ibm-aix': Invalid bfd target -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ben Elliston Sent: Tuesday, March 08, 2005 10:08 PM To: bug-binutils@gnu.org Subject: Re: Run objdump under windows XP for XCOFF object file created from IBM AIX system David Du wrote: > Hi, Ian, I tried both powerpc-aix and powerpc-elf, when I tested objdump -i, > they gave me error saying "objdump: can't set BFD default target to > powerpc-aix: Invalid bfd target" and "objdump: can't set BFD default target > to powerpc-unknown-elf: Invalid bfd target"; any other idea? At the risk of being the next bunny to answer a spate of newbie questions .. David, it sounds like you aren't running the right objdump. You may have one installed with Cygwin already. When you build binutils, where are you installing it with `make install'? Are you sure that when you run `objdump', it's the one you're expecting? Try `which objdump' to be sure. Ben ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
x86-64: gas could do a better job on movq imm32, r64
Hi, These two instructions are equivalent: movq $0x12345678, %rax movl $0x12345678, %eax But gas (2.17.50.0.12 on Fedora 7) chooses a longer encoding for the former: 22: 48 c7 c0 78 56 34 12mov$0x12345678,%rax 29: b8 78 56 34 12 mov$0x12345678,%eax In fact, for any non-negative immediate constant that fits in 32 bits, it's better to use the "mov imm32, r32" instruction (0xb8), rather than "mov imm32, r64" (REX 0xc7). Negative constants need the sign-extending effect of REX 0xc7. gcc-generated assembly doesn't seem to run into this, but hand-coded assembly often does (see for example the x86-64 Linux kernel). David Wragg ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
gprof reporting zero times for one program
I'm having issues with gprof reporting empty times on the development version of my network program nettee. For a "normal" program (reads and writes files, no network) the results show reasonable times. In fact, for the last release of nettee (0.1.8) gprof worked too. However for the version I'm working on now gprof only shows 0.0 in the time fields. Software: Mandriva 2007.1 Dual Opterons binutils-2.17.50.0.9-1mdv2007.1 gcc-4.1.2-1mdv2007.1 This works as expected: gcc -pg -O0 -g -lm -o fastaproperties fastaproperties.c gunzip -c /usr/common/BLASTDB/dm_dna.nt.gz |./fastaproperties - gprof -l fastaproperties > goo.txt with output like (sorry about the wrap): Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ts/call Ts/call name 56.73 0.60 0.60 main (fastaproperties.c:148 @ 8048ddb) 23.84 0.85 0.25 main (fastaproperties.c:147 @ 8048e15) 9.54 0.95 0.10 main (fastaproperties.c:144 @ 8048d8d) 4.29 0.99 0.05 main (fastaproperties.c:147 @ 8048dd2) Whereas for the development nettee: gcc -Wall -DNOUSLEEP -D_LARGEFILE64_SOURCE -D_POSIX_SOURCE -pg -O0 -g -o nettee nettee.c rb.c nio.c ./nettee -v 255 -next monkey01 -in - stderr.log #this copies that largish file to node monkey01 in about 6 seconds gprof -l nettee >foo.txt produces (again, sorry about the wrap): Flat profile: Each sample counts as 0.01 seconds. no time accumulated % cumulative self self total time seconds secondscalls Ts/call Ts/call name 0.00 0.00 0.00 608 0.00 0.00 rb_shadow_set_reconcile (rb.c:427 @ 8051b70) 0.00 0.00 0.00 330 0.00 0.00 writenbytes_noblock_n (nio.c:1267 @ 805579d) 0.00 0.00 0.00 315 0.00 0.00 readnbytes_noblock_n (nio.c:1323 @ 80558a0) 0.00 0.00 0.00 311 0.00 0.00 write_rb_noblock_n (nio.c:1155 @ 80554fc) 0.00 0.00 0.00 297 0.00 0.00 read_rb_noblock_n (nio.c:1105 @ 805537f) This is not very helpful. The program uses a standard sort of network methodology, where it runs in a while loop using FD_SET, runs select, and then reads/writes from/to those inputs/outputs which select has marked as ready. I know the program spends 99% of its time in a routine called transmit(), where all of this work is performed, but transmit is at the very end of the first list and looks like this: 0.00 0.00 0.001 0.00 0.00 transmit (nettee.c:1306 @ 804b7b1) I tried transferring a larger file which took 20 seconds, but still all the fields held 0.00 seconds. Here's the older version: gcc -Wall -DNOUSLEEP -D_LARGEFILE64_SOURCE -D_POSIX_SOURCE -pg -g -o -O0 nettee ../nettee-0.1.8/nettee.c ./nettee -v 255 -next monkey01 -in - stderr.log gprof -l nettee >foo.txt which looks fine: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ts/call Ts/call name 54.29 0.19 0.19 writenbytes (nettee.c:913 @ 804a30a) 30.00 0.30 0.11 writenbytes (nettee.c:914 @ 804a326) 12.86 0.34 0.05 writenbytes (nettee.c:916 @ 804a32c) 2.86 0.35 0.01 writenbytes (nettee.c:912 @ 804a359) 0.00 0.35 0.0034071 0.00 0.00 readnbytes (nettee.c:933 @ 804a36a) What could be the problem in the new version of this program which is so confusing gprof? I've run nettee in valgrind and it was well behaved running in there (albeit really slow). Thanks, David Mathog [EMAIL PROTECTED] Manager, Sequence Analysis Facility, Biology Division, Caltech ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gprof reporting zero times for one program
Nick Clifton wrote: > > Whereas for the development nettee: > > > Each sample counts as 0.01 seconds. > > no time accumulated > > Hmm, well it appears that there is no profiling information in the gmon.out > file. Have you checked that a gmon.out file is actually being produced ? And > that it is not empty ? gmon.out is created and is not empty. It contains some information as the "called" columns have reasonable values, it is just times that are all zero. > > My first guess as to the cause would be that you are now linking with startup > files which do not enable profiling. I did that for an old version (which will profile) and the new one (which will not) and could not see anything obviously different in the two. Try adding "-v" to the gcc command line > of the old and new nettee builds and see if different startup files are being used. The -v output looks the same, except for the lines in the new one which result from the compile of the two new nio.c and rb.c files, that is, the build for the previous one was: gcc -Wall -DNOUSLEEP -D_LARGEFILE64_SOURCE -D_POSIX_SOURCE -v -pg -g -O0 -v -o nettee nettee.c>previous_v.txt 2>&1 and for the current one: gcc -Wall -DNOUSLEEP -D_LARGEFILE64_SOURCE -D_POSIX_SOURCE -v -pg -g -O0 -o nettee nettee.c rb.c nio.c >current_v.txt 2>&1 ldd shows the same entries for both binaries. I wonder if maybe this isn't some issue related to secondary files rb.c and nio.c? I tried export GPROF_PATH=/(the path) gprof -l nettee and while the times were all zero it did have line numbers in rb.c and nio.c. So it found the source files and could read them ok. Here are the first two useful lines of gprof -l which show that it could resolve line numbers in both nettee.c and rb.c, sorry about the wrap: 0.000.007339/7339transmit (nettee.c:1576 @ 804c5c8) [2241] [2] 0.00.000.007339 rb_shadow_set_reconcile (rb.c:427 @ 8052518) [2] The time, self, and children fields are all zero, but the called graph seems about right. > > You might also try using the gcov program as an alternative to gprof (and > --coverage instead of -pg). That ran and provided exactly the same coverage information which was already in gprof, but no times. Maybe I'm missing something but I do not see how to induce gcov to emit execution times per line. gcc -Wall -DNOUSLEEP -D_LARGEFILE64_SOURCE -D_POSIX_SOURCE -coverage -g -O0 -o nettee nettee.c rb.c nio.c (run nettee on a transfer that took 38 seconds) gcov nettee The only change other than the use of multiple files, instead of just one, that I can think of which might be causing this is that the new version of nettee calls alarm(0) and alarm(time) more frequently than did the previous version. If gprof embeds code which uses the same mechanism it might never be seeing its timers going off. Other than that, the rest of the code changes are just that - code changes, there shouldn't be anything in normal logic to confuse gprof. Valgrind runs cleanly so it isn't stomping on memory. Thanks, David Mathog [EMAIL PROTECTED] Manager, Sequence Analysis Facility, Biology Division, Caltech ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
binutils-2.21.53.0.2/gas bug report
Hello there, I just ran the static analysis tool cppcheck over the source code of binutils-2.21.53.0.2. It said 1. [binutils-2.21.53.0.2/gas/config/tc-mn10200.c:483]: (warning) Redundant assignment of "opcode" in switch The source code is case 0xff: opcode = 0xfe; case 0xe8: There looks to be a missing break in there. 2. [binutils-2.21.53.0.2/gas/config/tc-mn10200.c:563]: (warning) Redundant assignment of "opcode" in switch Duplicate. Regards David Binderman ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
LFLAGS+=-Wl,-q causes ld to signal 11 during collect2
I have spent the past couple of days tracking down why my builds all fail with collect2: ld terminated with signal 11 [Segmentation fault] This was 100% repeatable with binutils 2.20 and 2.22, on multiple architectures (X86 and ARM). I finally found that the cause was passing LFLAGS+=-Wl,-q to the compiler (asking LD to emit relocation records). Removing this flag allowed the link to run. Since Google-ing for this error never seems to yield any sort of suggestions to try to fix this, I thought I'd share my results. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
tc-v850.c:1663: possible bad if condition ?
Hello there, [src/gas/config/tc-v850.c:1663]: (style) Expression is always false because 'else if' condition matches previous condition at line 1655. Source code is else if (strcmp (arg, "8byte-align") == 0) v850_data_8 = TRUE; else if (strcmp (arg, "4byte-align") == 0) v850_data_8 = FALSE; else if (strcmp (arg, "soft-float") == 0) soft_float = 1; else if (strcmp (arg, "hard-float") == 0) soft_float = 0; else if (strcmp (arg, "8byte-align") == 0) v850_e_flags |= EF_RH850_DATA_ALIGN8; else if (strcmp (arg, "4byte-align") == 0) v850_e_flags &= ~ EF_RH850_DATA_ALIGN8; The last two conditions will never be true. Suggest code rework. Regards David Binderman ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
pdp-11 TARGET_PAGE_SIZE mismatch in 2.25
In binutils-2.25 the files pfd/pdp11.c and ld/emulparams/pdp11.sh both define TARGET_PAGE_SIZE but the values are different. This causes weirdness in the linker output, namely symbol values are set by one while the sections' lma/vma values are set by the other. I went with the smaller value (256 instead of 1024) for my purposes because the pdp-11 is so memory limited but maybe somewhere else there's good reason for the larger number. -Dave ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: pdp-11 TARGET_PAGE_SIZE mismatch in 2.25
In my previous message I jumped to the fix, rather than giving you just the problem. Sorry about that. Here's a little program: crt0.s: .text .even .globl _start _start: mov$014, sp movsp, r5 movargv, -(sp)/* argv */ mov$1, -(sp)/* argc */ jsrpc, ___main add$4, sp halt rtspc .even .globl ___main ___main: rts pc .data arg1:.asciz"stand-alone" .even argv:.wordarg1 Now run: dab@malabar> pdp11-aout-as -o crt0.o crt0.s dab@malabar> pdp11-aout-ld -nostdlib -o crt0 crt0.o dab@malabar> pdp11-aout-objdump -x crt0 crt0: file format a.out-pdp11 crt0 architecture: pdp11, flags 0x00be: EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, WP_TEXT start address 0x Sections: Idx Name Size VMA LMA File off Algn 0 .text 001c 0010 2**1 CONTENTS, ALLOC, LOAD, CODE 1 .data 000e 0400 0400 002c 2**1 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0002 040e 040e 2**1 ALLOC SYMBOL TABLE: l .text 00 02 crt0.o g .text 00 22 _start 010c l .data 00 03 argv 001a g .text 00 22 ___main 0100 l .data 00 03 arg1 001c g .text 00 22 __etext 001c g .text 00 22 _etext 0110 g .bss 00 24 __end 010e g .data 00 23 __edata 010e g .bss 00 24 __bss_start 010e g .data 00 23 _edata 0110 g .bss 00 24 _end Notice in the symbol table that arg1, the first item in the .data segment, has the value 100 while the VMA and LMA of the .data segment are 400. I tried setting TARGET_PAGE_SIZE in bfd/pdp11.c to 256, the same value it has in ld/emulparams/pdp11.sh, and that disagreement went away. -Dave ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
src/gold/arm.cc:4513: de-allocation then use ?
Hello there, [src/gold/arm.cc:4513]: (error) Returning/dereferencing 'buffer' after it is deallocated / released Source code is delete[] buffer; return std::string(buffer); Suggest code rework. Regards David Binderman ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
src/gdb/remote.c:7724: missing use of va_end ?
Hello there,
[src/gdb/remote.c:7724]: (error) va_list 'ap' was opened but not closed by
va_end().
Source code is
va_start (ap, format);
rs->buf[0] = '\0';
if (vsnprintf (rs->buf, max_size, format, ap)>= max_size)
internal_error (__FILE__, __LINE__, _("Too long remote packet."));
if (putpkt (rs->buf) < 0)
error (_("Communication problem with target."));
rs->buf[0] = '\0';
getpkt (&rs->buf, &rs->buf_size, 0);
return packet_check_result (rs->buf);
Regards
David Binderman
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
bfd/elf32-nds32.c:9693]: (warning) Redundant assignment
Hello there, bfd/elf32-nds32.c:9693]: (warning) Redundant assignment of 'irel->r_addend' to itself. Source code is rel->r_offset = rel->r_offset; Suggest code rework. Regards David Binderman ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
bfd/elf32-arc.c:1537]: (warning) Redundant assignment
Hello there, bfd/elf32-arc.c:1537]: (warning) Redundant assignment of 'rel->r_offset' to itself. Source code is rel->r_offset = rel->r_offset; Suggest code rework. Regards David Binderman ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[PATCH] RISC-V: prevent null pointer dereference
Signed-off-by: David Michael --- Hi, I tried to test the Linux RISC-V UEFI stub by cross-compiling this branch with binutils 2.34 and GCC 9.3.0: https://github.com/atishp04/linux/tree/uefi_riscv_pr It results in a segfault in ld while linking vmlinux because the pointer h->root.u.def.section is NULL in one instance. This change fixes the segfault and results in a usable UEFI kernel, but I am not familiar with this code, so I don't know if it is the correct behavior. Can someone verify this? Let me know if you need configs etc. Thanks. David bfd/elfnn-riscv.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bfd/elfnn-riscv.c b/bfd/elfnn-riscv.c index 8fcb1067..65b4f141 100644 --- a/bfd/elfnn-riscv.c +++ b/bfd/elfnn-riscv.c @@ -4161,7 +4161,8 @@ _bfd_riscv_relax_section (bfd *abfd, asection *sec, symval = 0; sym_sec = bfd_und_section_ptr; } - else if (h->root.u.def.section->output_section == NULL + else if (h->root.u.def.section == NULL + || h->root.u.def.section->output_section == NULL || (h->root.type != bfd_link_hash_defined && h->root.type != bfd_link_hash_defweak)) continue; -- 2.21.1
ar: undefined symbol: bfd_plugin_set_program_name
I find such a problem when cross compile binutils 2.20; the following are logs in terminal: libtool: link: ar cru .libs/libbfd.a archive.o archures.o bfd.o bfdio.o bfdwin.o cache.o coffgen.o corefile.o format.o init.o libbfd.o opncls.o reloc.o section.o syms.o targets.o hash.o linker.o srec.o binary.o tekhex.o ihex.o stabs.o stab-syms.o merge.o dwarf2.o simple.o compress.o verilog.o elf32-arm.o elf32.o elf-vxworks.o elf.o elflink.o elf-attrs.o elf-strtab.o elf-eh-frame.o dwarf1.o elf32-gen.o cpu-arm.o ar: symbol lookup error: ar: undefined symbol: bfd_plugin_set_program_name make[4]: *** [libbfd.la] Error 127 make[4]: Leaving directory `/work/arm-linux-gnueabi/build/binutils-build/bfd' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/work/arm-linux-gnueabi/build/binutils-build/bfd' make[2]: *** [all] Error 2 make[2]: Leaving directory `/work/arm-linux-gnueabi/build/binutils-build/bfd' make[1]: *** [all-bfd] Error 2 make[1]: Leaving directory `/work/arm-linux-gnueabi/build/binutils-build' make: *** [all] Error 2 ./arm-cross-1.2.sh: 114: Syntax error: "&&" unexpected -- View this message in context: http://old.nabble.com/ar%3A-undefined-symbol%3A-bfd_plugin_set_program_name-tp26404888p26404888.html Sent from the Gnu - Binutils - Bugs mailing list archive at Nabble.com. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ar: undefined symbol: bfd_plugin_set_program_name
Following is my configure options:
AR=ar AS=as ${SRCDIR}/binutils-2.20/configure --prefix=${CLFSCROSSTOOL} \
--host=${CLFS_HOST} --target=${CLFS_TARGET} --with-sysroot=${CLFS} \
--disable-nls --enable-shared --disable-multilib
make configure-host
make
Alan Modra wrote:
>
> On Wed, Nov 18, 2009 at 01:37:55AM -0800, david levis wrote:
>> ar: symbol lookup error: ar: undefined symbol:
>> bfd_plugin_set_program_name
>
> Please show the options you passed to configure.
>
> --
> Alan Modra
> Australia Development Lab, IBM
>
>
> ___
> bug-binutils mailing list
> bug-binutils@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-binutils
>
>
--
View this message in context:
http://old.nabble.com/ar%3A-undefined-symbol%3A-bfd_plugin_set_program_name-tp26404888p26585955.html
Sent from the Gnu - Binutils - Bugs mailing list archive at Nabble.com.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ar: undefined symbol: bfd_plugin_set_program_name
I replaced binutils 2.20 downloaded from gnu.org with kernel.org. Now
everything works.
david levis wrote:
>
> I am under Ubuntu 9.10 & gcc version is
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 4.4.1-4ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --enable-multiarch --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all
> --disable-werror --with-arch-32=i486 --with-tune=generic
> --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
> --target=i486-linux-gnu
> Thread model: posix
> gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8)
>
> Following is my configure options:
>
>
> AR=ar AS=as ${SRCDIR}/binutils-2.20/configure --prefix=${CLFSCROSSTOOL} \
>--host=${CLFS_HOST} --target=${CLFS_TARGET} --with-sysroot=${CLFS} \
>--disable-nls --enable-shared --disable-multilib
>
> make configure-host
> make
>
>
> Alan Modra wrote:
>>
>> On Wed, Nov 18, 2009 at 01:37:55AM -0800, david levis wrote:
>>> ar: symbol lookup error: ar: undefined symbol:
>>> bfd_plugin_set_program_name
>>
>> Please show the options you passed to configure.
>>
>> --
>> Alan Modra
>> Australia Development Lab, IBM
>>
>>
>> ___
>> bug-binutils mailing list
>> bug-binutils@gnu.org
>> http://lists.gnu.org/mailman/listinfo/bug-binutils
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/ar%3A-undefined-symbol%3A-bfd_plugin_set_program_name-tp26404888p26897618.html
Sent from the Gnu - Binutils - Bugs mailing list archive at Nabble.com.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
More complete fix for a previous problem in gprof.
Here is a patch to correct a previous gprof bug that was only partially
fixed. Apparently it is possible for GCC to clone its own cloned
functions.
This problem manifested in a large g++ application which I cannot
provide in source form. Furthermore, simplification of that example
eliminates the problem with high probability. The best evidence I can
provide is the following gdb session showing the boundary between two
functions that demonstrates such a "clone of a clone":
(gdb) x/5i 0x7a7ae8
0x7a7ae8 <_ZN10sims_Event15startSimulationEv+552>:
callq 0x7a6f40 <_ZN19trno_WarningMessagelsEPKc.clone.4>
0x7a7aed <_ZN10sims_Event15startSimulationEv+557>:
jmp0x7a7ab8 <_ZN10sims_Event15startSimulationEv+504>
0x7a7aef: nop
0x7a7af0
<_ZNKSt6vectorIPN10sims_Event9EventLinkESaIS2_EE12_M_check_lenEmPKc.clone.45.clone.53>:
push %rbp
0x7a7af1
<_ZNKSt6vectorIPN10sims_Event9EventLinkESaIS2_EE12_M_check_lenEmPKc.clone.45.clone.53+1>:
mov%rsp,%rbp
(gdb)
Note the .clone.45.clone.53 suffix on the symbol.
The following patch accepts function symbols that match the following
extended regular expression:
^[^\$\.]*(\.(clone\.)?[0-9]+)+$
and so accepts the following symbols:
foo.123
foo.clone.23
foo.clone.1.clone.2
foo.2.clone.6.clone.9
foo.2.1.clone.3.4.clone.5
This errs on the side of accepting more cases than the relevent
mechanisms are likely to produce (e.g., the last example).
David
--- orig/gprof/corefile.c 2011-06-06 10:07:57.406964819 -0400
+++ fixed/gprof/corefile.c 2011-06-06 10:15:10.198544726 -0400
@@ -389,16 +389,21 @@
if (*name == '.')
{
- /* Allow GCC cloned functions. */
- if (strlen (name) > 7 && strncmp (name, ".clone.", 7) == 0)
- name += 6;
-
- /* Do not discard nested subprograms (those
-which end with .NNN, where N are digits). */
- for (name++; *name; name++)
- if (! ISDIGIT (*name))
+ /* Allow both nested subprograms and GCC cloned functions.
+Apparently, GCC can clone both of these. */
+ do {
+ if (strlen (name) > 7 && strncmp (name, ".clone.", 7) == 0)
+ name += 6;
+ int digit_seen = 0;
+ /* Do not discard nested subprograms (those
+ which end with .NNN, where N are digits). */
+ for (name++; *name; name++)
+ if (digit_seen && *name == '.') break;
+ else if (ISDIGIT (*name))
+ digit_seen = 1;
+ else
return 0;
-
+ } while (*name == '.');
break;
}
}
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/818] New: error handling %farg[0-4] registers
> 2005-04-11 Nick Clifton <[EMAIL PROTECTED]> > > PR gas/818 > * config/tc-hppa.c (pre_defined_registers): Fix %farg[0-3] > synonyms. Yes, the change looks correct. Ok. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
objdump not breakable
I was messing with the alignments of sections in the linker command file. On one of the invocations, the objdump was creating a 8 MB file after I made an alignment change (was meant only to be 1 MB). I tried to kill the objdump; but, it kept running. I started task manage and tried to end objdump; but, still kept executing. objdump needs to be built such that it is breakable ! Target platform: NXP T2081 GNU objdump (GNU Binutils) 2.28.0.20170307 Compiler: gcc (GCC) 6.4.0 Host OS: Windows 10 Pro +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- David Cooper, "Coop" Abaco Systems, Principal Software Engineer - CERT 27 Blazing Star, Irvine, Ca, 92604 USA (home office) Mobile: 1-949-463-9013 Direct Dial: 1-866-OK-ABACO (1-866-652-2226) x5026 Skype: david.coo...@abaco.com linkcmds Description: linkcmds
[Bug ld/19962] New: R_ARM_COPY relocation generated with -znocopyreloc
https://sourceware.org/bugzilla/show_bug.cgi?id=19962 Bug ID: 19962 Summary: R_ARM_COPY relocation generated with -znocopyreloc Product: binutils Version: 2.25 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: david at zentus dot com Target Milestone: --- Linking with -znocopyreloc has no effect on ARM. The result binary still contains an R_ARM_COPY relocation. $ cat data-ref.s .globl _start .p2align 4 _start: bkpt .data .globl data_object object_reference: .long data_object .size object_reference,4 $ cat libdata.s .data .globl data_object .type data_object, %object .size data_object, 4 data_object: .long 123 $ as -o data-ref.o data-ref.s $ as -o libdata.o libdata.s $ ld.bfd -shared -o libdata.so libdata.o $ ld.bfd -znocopyreloc -o data-ref data-ref.o libdata.so $ readelf -r data-ref Relocation section '.rel.dyn' at offset 0x20c contains 1 entries: Offset InfoTypeSym.Value Sym. Name 000202c0 0314 R_ARM_COPY000202c0 data_object Linking with ld.gold does the right thing: Relocation section '.rel.dyn' at offset 0x19c contains 1 entries: Offset InfoTypeSym.Value Sym. Name 9240 0102 R_ARM_ABS32 data_object Related to bug 16177 (I borrowed the example program from there). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/10856] [2.20 regression] gas creates wrong code which results in a test failure in libcrypto++'s sha2 test
--- Additional Comments From david-sarah at jacaranda dot org 2009-12-13 17:55 --- Any indication of when this fix is likely to get into a release? The more OS distributions as 2.20 goes into, the more problems this bug will cause. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10856 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/3163] New: Provide example of assignment to a symbol within a section in linker scripts
It should be made clear by use of an example that assignment of an absolute
expression to a symbol within an output section description will result in the
symbol having the value ADDR(section) + (value of absolute expression) rather
than just the value.
This is the intended behaviour as noted by the response to this bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=458.
Section 3.5.1 (Simple Assignments) would seem a good place to clarify this. I
suggest changing the example from:
" floating_point = 0;
SECTIONS
{
.text :
{
*(.text)
_etext = .;
}
_bdata = (. + 3) & ~ 3;
.data : { *(.data) }
}
In this example, the symbol `floating_point' will be defined as
zero. The symbol `_etext' will be defined as the address following the
last `.text' input section. The symbol `_bdata' will be defined as the
address following the `.text' output section aligned upward to a 4 byte
boundary."
to:
" floating_point = 0;
SECTIONS
{
.text 0x50 :
{
_small_offset = 4;
*(.text)
_etext = .;
}
_absolute_value = 8;
_bdata = (. + 3) & ~ 3;
.data : { *(.data) }
}
In this example, the symbol `floating_point' will be defined as zero. The
symbol '_small_offset' will be defined as 0x54 since it is relative to the start
of the '.text' output section. The symbol `_etext' will be defined as the
address following the last `.text' input section. The symbol '_absolute_value'
will be defined as 8. The symbol `_bdata' will be defined as the address
following the `.text' output section aligned upward to a 4 byte boundary."
A change of this sort should prevent confusion/invalid bug reports.
--
Summary: Provide example of assignment to a symbol within a
section in linker scripts
Product: binutils
Version: 2.17
Status: NEW
Severity: enhancement
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: david dot cook at st dot com
CC: bug-binutils at gnu dot org
http://sourceware.org/bugzilla/show_bug.cgi?id=3163
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
