Re: [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel.
On Fri, 2005-10-07 at 04:32 +, hjl at lucon dot org wrote: > --- Additional Comments From hjl at lucon dot org 2005-10-07 04:32 > --- > Will this kernel change fix the kernel? Will this kernel change work with > the old assembler? The patch will work regardless of what slot the assembler uses for the tag, so yes it will work for both the old and new assemblers. I don't know if it will fix the kernel. You will have to try it. It looks like it will fix the one problem you identified. There could be other problems, though it seems unlikely. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug gas/1434] IA64 assembler generates different debug info
On Fri, 2005-10-07 at 04:30 +, hjl at lucon dot org wrote: > --- Additional Comments From hjl at lucon dot org 2005-10-07 04:30 > --- > The difference is I don't think this alone will cause kernel boot problem. So there is no actual bug here apparently. You just noticed the debug info was different. In that case, the answer is yes it is different, and the difference is accidental, however, since the old debug info was technically wrong, I think we should keep the new behaviour. And yes, this is the same problem as PR 1433. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug ld/3191] Dwarf 2 reader in linker doesn't suppor DW_FORM_ref_addr
On Wed, 2006-09-20 at 19:02 +, hjl at lucon dot org wrote: > When reporting linker error, dwarf2 reader doesn't support more than one > .debug_info section. You can only have more than one debug_info section when -feliminate-dwarf2-dups is used. This isn't a commonly used option, and there may be a number of problems with it. This is allowed by DWARF3, but not by DWARF2. I see how your patch might help now. The debug info is 32-bits as I mentioned earlier. The problem here is that pointers are 64-bits. read_address uses addr_size, and hence is reading a 64-bit address when it should be reading a 32-bit address, thus getting a number that is too large. Your fix adding 64-bit debug support helps because in the 32-bit case you replaced the read_address call with a read_4_bytes call, which correctly reads the 32-bit value we want. However, this is speculation, as I don't know how to reproduce the failure. I don't understand why this hasn't come up before. Also, it isn't clear what this has to do with the further information you have provided about multiple debug_info sections. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/3276] New: Alignment error with static const variable in inline function
On Thu, 2006-09-28 at 07:42 +, jespdj at hotmail dot com wrote: > g++ outputs the correct assembler code, so the error must be in as or ld. Or, more likely, in the OS. Try running objdump -x on your executable. If the .rdata section has alignment 2**4, then the linker is OK. It is your OS (i.e. the loader) that isn't respecting the alignment. I tried this on an i386-cygwin system, and it looked OK to me. The rdata section has the right alignment, and the program worked. I didn't do this with binutils-2.17 though. I used the one I already had. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Error: can't resolve `.hcu.uncommon_code' {.hcu.uncommon_code section} - `.LFB17' {.text section}
On Fri, 2007-04-20 at 18:55 -0700, Kristis Makris wrote:
> /tmp/ccAyM42z.s: Assembler messages:
> /tmp/ccAyM42z.s:787: Error: can't resolve
> `.hcu.uncommon_code' {.hcu.uncommon_code section} - `.LFB17' {.text
> section}
You are subtracting symbols in different ELF object file sections. This
is not an assemble time constant since we don't know where the sections
will end up in the output. Since this value is used in a context that
requires a constant, the assembler is forced to give an error.
787 is the line number. Look at this line and we see
.long .LFE17-.LFB17
Then look above for the definitions of these labels, and we see LFB17 is
at the start of main, which is in the text section, and LFE17 is at the
end of main, which is in the .hcu.uncommon_code section, which clearly
won't work. You can't start a function in one section and end it in
another section.
It looks like you are trying to do some complicated (and probably
fragile) section switching stuff in a C function using gcc extended
asms, and that there is an unbalanced section switch somewhere. Or
maybe gcc optimization is breaking your code.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Error: can't resolve `.hcu.uncommon_code' {.hcu.uncommon_code section} - `.LFB17' {.text section}
On Mon, 2007-04-23 at 09:34 -0700, Kristis Makris wrote: > It seems that gcc does not even produce the inline assembly after the > last goto, perhaps because it is deemed that it's dead code. Seems right. > However, I > need this assembly produced to emit the section change to ".text". Is > there a way to tell gcc to NOT remove that inline assembly ? Is there > some attribute/keyword that describes this ? I haven't found one. There is no such option or attribute. The problem here is that you are doing things behind the compiler's back. Long term, this isn't going to work. In the gcc docs, we mention that you aren't allowed to put control flow (branches/labels) into extended asms. GCC can't optimize properly if it can't compute the control-flow graph. Over time, the CFG is getting more and more important for optimization, and programs that violate this principle are more and more likely to fail. > The only other alternative I see is to acquire the value of the > hcu_wrapped_main_0_before label using the && operator This is the only thing that occurred to me. Make sure the label is used somehow, and that prevents gcc from optimizing away dead code. However, over time, as gcc gets smarter, you will have to try harder to fool it into believing that the label is actually used. Simply using the label in an extended asm may not be good enough, as gcc knows that asms aren't allowed to contain branches. You may need to store it in a static variable, and add a goto *labeladdr someplace. Note that use of &&label confuses the CFG, effectively disabling some optimizations, which means that you may lose performance when you do this. I think you should rethink your whole approach. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/4791] etc/standards.texi: @strong{Note...} produces a spurious cross-reference in Info
On Wed, 2007-08-01 at 16:05 +, nightstrike at gmail dot com wrote: > Proposed patch to change two lines in standards.texi standards.texi is not a binutils file, it is an FSF documentation file. It is wrong to change the wording of it without approval from the FSF. A better solution is to import a new version from upstream, which hopefully already has this fixed. If not, then we should be reporting the bug upstream so they can fix it, and so we can then import a fixed version. See http://www.gnu.org/prep/standards/ It looks like this problem has already been fixed upstream, though I didn't look at this very closely. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/4791] etc/standards.texi: @strong{Note...} produces a spurious cross-reference in Info
On Wed, 2007-08-01 at 23:10 +, nightstrike at gmail dot com wrote: > I didn't realize there was the hierarchy you describe. Where is the cvs > repository for the "upstream"? The project page is here http://savannah.gnu.org/projects/gnustandards You can get to the cvs repository for this project from there, under Development Tools. -- Jim Wilson, GNU Tools Support, http://www.specifix.com ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: gas for itanium: ia64-ic.tbl: dependency bug due to error in the itanium specification
On Thu, 2007-08-02 at 14:18 +0200, Lars wrote: > in the group 'fp-non-arith', xma is listed, but not xmpy. hence simply > adding also xmpy there will do the trick. This is correct. This is a bug in the Intel documentation. HJ, can you report this internally within Intel to get the docs fixed? Additionally, I noticed that the class pr-readers-nobr-nomovpr contains fp-non-arith in addition to xma and xmpy which is redundant. The xma and xmpy could be deleted here. This is a harmless error though. I wrote a patch to fix gas. I just fixed the fp-non-arith problem, I didn't bother with the other one as it doesn't matter. With this patch, I now get the following objdump -d output for the assembled testcase, which is correct. 0: 0f 30 3c 00 e1 18 [MMF] setf.sig f6=r15 6: 70 80 00 c2 31 00 setf.sig f7=r16 c: 00 00 04 00 nop.f 0x0;; 10: 0d 00 00 00 01 00 [MFI] nop.m 0x0 16: 50 00 18 0e 74 00 xmpy.l f5=f6,f7 1c: 00 00 04 00 nop.i 0x0;; 20: 01 70 14 00 e1 10 [MII] getf.sig r14=f5 26: 00 00 00 02 00 00 nop.i 0x0 2c: 00 00 04 00 nop.i 0x0;; When regenerating ia64-asmtab.c, I noticed that a newline was accidentally deleted when the copyright messages were updated, so I included that in my patch too. The patch was tested with make check on an x86_64-linux host and checked in. -- Jim Wilson, GNU Tools Support, http://www.specifix.com 2007-08-03 James E. Wilson <[EMAIL PROTECTED]> * ia64-gen.c: (main): Add missing newline to copyright message. * ia64-ic.tbl (fp-non-arith): Add xmpy. * ia64-asmtab.c: Regenerate. Index: ia64-gen.c === RCS file: /cvs/src/src/opcodes/ia64-gen.c,v retrieving revision 1.21 diff -p -r1.21 ia64-gen.c *** ia64-gen.c 5 Jul 2007 09:49:01 - 1.21 --- ia64-gen.c 3 Aug 2007 18:45:25 - *** main (int argc, char **argv) *** 2872,2878 You should have received a copy of the GNU General Public License\n\ along with this program; see the file COPYING. If not, write to the\n\ Free Software Foundation, 51 Franklin Street - Fifth Floor, Boston, MA\n\ !02110-1301, USA. */"); print_string_table (); print_dependency_table (); --- 2872,2878 You should have received a copy of the GNU General Public License\n\ along with this program; see the file COPYING. If not, write to the\n\ Free Software Foundation, 51 Franklin Street - Fifth Floor, Boston, MA\n\ !02110-1301, USA. */\n"); print_string_table (); print_dependency_table (); Index: ia64-ic.tbl === RCS file: /cvs/src/src/opcodes/ia64-ic.tbl,v retrieving revision 1.9 diff -p -r1.9 ia64-ic.tbl *** ia64-ic.tbl 23 Feb 2006 00:17:24 - 1.9 --- ia64-ic.tbl 3 Aug 2007 18:45:25 - *** fp-arith-s0; IC:fp-arith[Field(sf)==s0] *** 15,21 fp-arith-s1; IC:fp-arith[Field(sf)==s1] fp-arith-s2; IC:fp-arith[Field(sf)==s2] fp-arith-s3; IC:fp-arith[Field(sf)==s3] ! fp-non-arith; fabs, fand, fandcm, fclass, fcvt.xf, fmerge, fmix, fneg, fnegabs, for, fpabs, fpmerge, fpack, fpneg, fpnegabs, fselect, fswap, fsxt, fxor, xma fpcmp-s0; fpcmp[Field(sf)==s0] fpcmp-s1; fpcmp[Field(sf)==s1] fpcmp-s2; fpcmp[Field(sf)==s2] --- 15,21 fp-arith-s1; IC:fp-arith[Field(sf)==s1] fp-arith-s2; IC:fp-arith[Field(sf)==s2] fp-arith-s3; IC:fp-arith[Field(sf)==s3] ! fp-non-arith; fabs, fand, fandcm, fclass, fcvt.xf, fmerge, fmix, fneg, fnegabs, for, fpabs, fpmerge, fpack, fpneg, fpnegabs, fselect, fswap, fsxt, fxor, xma, xmpy fpcmp-s0; fpcmp[Field(sf)==s0] fpcmp-s1; fpcmp[Field(sf)==s1] fpcmp-s2; fpcmp[Field(sf)==s2] ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Errors in the opcodes-2.17.90 PO file
On Wed, 2007-09-26 at 17:09 +0100, Nick Clifton wrote:
> * ia64-gen.c (print_dependency_table): Likewise.
You accidentally replaced %s with %, which results in a compiler error
with -Werror. This only shows up if you do a maintenance build, or
build ia64-gen by hand.
../../src/opcodes/ia64-gen.c:1556: warning: unknown conversion type
character 0xa in format
I checked in the following patch to fix this. I regenerated
ia64-asmtab.c and verified that there was no change to it, and hence no
changes to any installed binaries.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
2007-09-26 James E. Wilson <[EMAIL PROTECTED]>
* ia64-gen.c (print_dependency_table): Fix typo in last patch.
Index: ia64-gen.c
===
RCS file: /cvs/src/src/opcodes/ia64-gen.c,v
retrieving revision 1.23
diff -p -r1.23 ia64-gen.c
*** ia64-gen.c 26 Sep 2007 16:07:18 - 1.23
--- ia64-gen.c 26 Sep 2007 18:03:59 -
*** print_dependency_table ()
*** 1552,1558
if (rdeps[i]->total_chks == 0)
{
if (rdeps[i]->total_regs)
! warn (_("Warning: rsrc %s (%s) has no chks%\n"),
rdeps[i]->name, mode_str[rdeps[i]->mode]);
else
warn (_("Warning: rsrc %s (%s) has no chks or regs\n"),
--- 1552,1558
if (rdeps[i]->total_chks == 0)
{
if (rdeps[i]->total_regs)
! warn (_("Warning: rsrc %s (%s) has no chks\n"),
rdeps[i]->name, mode_str[rdeps[i]->mode]);
else
warn (_("Warning: rsrc %s (%s) has no chks or regs\n"),
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: cannot restore segment prot after reloc
Paul Turner wrote: What does this mean "cannot restore segment prot after reloc? The message is from the dynamic linker, which is part of glibc. See the glibc file elf/dl-reloc.c. It means that you have a read-only section (like text) that contains relocs that require modifying the read-only section. This requires a mprotect call before we can modify it, and a second mprotect call after the fact to make the section read-only again after we change it. The second mprotect call failed. Of course, if you have a proper shared library, you should not have any relocs against the text section. Maybe you forgot to compile something as PIC? Jim ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Question about windows vista
Daniel Lopes wrote: Hi, I'm having problems with minGW.The problem is that i'm trying to install the program in the windows vista and almost in the middle of the install it stops .The last two messages are : "gzread: incomplete block read." "error: failure reading from tarball.".I think that the problem is the archive "binutils-2.17.50-20060824-1.tar"is.he is with error.Some archives of it don't open.I can't open this file.How can I resolve this problem? I'm brazilian, so sorry for my mistakes. The GCC developers don't have anything to do with these files at the mingw.org site. You should try contacting them. It is possible that the file got corrupted when you downloaded it. You could try downloading it again. Some sites put checksum files on their download sites, so that you can verify that files downloaded corrected. The GCC developers for instance use md5sum. The mingw.org site apparently doesn't do that though, which is unfortunate. Jim ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Question about windows vista
Jim Wilson wrote: The GCC developers Sorry, that should be "Binutils developers" not "GCC developers". I got my mailing lists confused. Otherwise the info is accurate. Jim ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: GNU Assembler (ARMv8 - Raspberry Pi 3)
On 04/12/2016 06:55 AM, Pervin, William wrote: The new Raspberry Pi 3 has a 64-bit ARMv8 processor (WiFi, Bluetooth, C, Python, Mathematica, FreeOffice, etc. all free with the still US$35 board!) Except that it ships with a 32-bit/armv7 kernel and user space, and you can't run 64-bit/armv8 code on a 32-bit/armv7 kernel. It isn't clear when or if a 64-bit kernel will be available. When/If they provide a 64-bit kernel and user space, then it will come with a 64-bit armv8 compiler. The Odroid C2 has a 64-bit kernel, but is apparently not stable yet. This is about 40 USD. There are 64-bit boards available from www.96boards.org that come with a reasonably stable 64-bit kernel and user space, including a compiler. These start at about 100 USD. would now like to get a 64-bit assembler from GNU. Is there one available? If not yet, when might it appear? Of course I also want a new C compiler to take advantage of the processor. Again, is there one yet? If you have access to an x86 Ubuntu machine, then "apt install gcc-aarch64-linux-gnu" will work to get a cross toolchain to aarch64. Linaro has minimally supported cross toolchain binaries for x86 Ubuntu available at http://releases.linaro.org/components/toolchain/binaries/ if you want a different toolchain than the one provided by the OS. Or you can build one from source. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld: once multiple symbol definitions are allowed, both definitions end up in the executable
On 01/11/2017 01:49 AM, Pavel Shishpor wrote: Could please someone advice is it a bug or a feature when we get both bodies of the functions with the same name in the executable once multiple symbol definitions are allowed? Here is the example showing the behavior: The only thing that the --allow-multiple-definitions option does is disable the error message that you would normally get. It doesn't change how the linker output is created. So yes, you will end up with both definitions in the output. It is best to avoid getting multiple definitions in the first place. If you want the linker to discard unused functions, then each function must be in its own section via gcc -ffunction-sections and then use the linker --gc-sections option. However, this may cause problems of its own, e.g. debug functions may disappear because they appear unused, it won't work for libraries where most functions are meant to be used by an application it is linked with, etc. Or alternatively, you can try making it a COMDAT function, then duplicates get dropped automatically. For your example, the duplicate f function is in the same text section as the main function, which can't be deleted. The assembler may resolve intra-section references itself. Which means editing the text section to remove the f function may break other things in the same section, which is unsafe, and hence the linker can't do it. Thus the requirement that we can only delete functions that are in their own section. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: ld: once multiple symbol definitions are allowed, both definitions end up in the executable
On Tue, Jan 17, 2017 at 6:56 AM, Pavel Shishpor wrote: > Thanks a lot for the answer: it put me on the right track. The > '-ffunction-sections' option works OK on toy examples though GNU linker > crashed when I tried the following on real-life object files compiled with > -ffunction-sections and -fdata-sections options enabled: > > for i in $object_files_original > do > objcopy --weaken $i # weaken symbols for linker not to complain > about multiple definitions > done > ld.bfd -r --gc-sections -u external_symbol1... > $object_files_with_replacement_fucntions $object_files_original -o > combined.o > > ld.bfd: BFD (GNU Binutils) 2.27 assertion fail elflink.c:8380 > > > Any clues how to debug it? You can try different GNU ld versions. Maybe it works in an earlier or later version. In general, -ffunction-sections and -gc-sections are not commonly used options. So they may not be as reliable as most other gcc/ld options. Normally, I suggest trying gold, but I don't know if it implements -gc-sections. They don't bother to support some of the less common BFD linker options. Debugging this will require some knowledge of how bfd and the linker works, which could take some time. But in general, debugging this is the same as most other programs, put a breakpoint at the assert, and try to work your way backwards to figure out what went wrong. If you want us to debug this, then you have to file a bug report via bugzilla that has a testcase that we can use to reproduce. Speaking of which, the bug-gcc mailing list isn't really meant for emailed bug reports. It is where bugzilla sends email. It is better to ask a question on the main list, or to file a bug report into bugzilla. > Also I have not tried COMDAT magic: looks like there are no any external > tweaks to put function to COMDAT sections but g++ decides on its own what > should be go to COMDAT sections. You are right. I thought we had an attribute or something. You might be able to do this by using a section attribute to put it in a linkonce section, but I'm not sure if that really works offhand. In general, as I mentioned earlier, it is best to avoid duplicate definitions to begin with, rather than try to fix them at link time. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: "-flto -O2" shouln't opt out "undefined reference" error
On 01/16/2017 10:32 AM, Xuefer wrote: without -flto or without -O2 produce good (expected) result: configure:5332: checking for dlsym ... It isn't the linker that is the problem here. It is the compiler. But it isn't a compiler bug. An optimizing compiler is supposed to optimize code like this. I'd say the main problem is trying to use -flto at configure time. This is likely to break lots of configure scripts. char (*f) (); However, this particular problem I can fix with gcc by changing this line to char (* volatile f) (); and now gcc won't optimize away the store, even with -flto. Unfortunately, I can't check LLVM at the moment, as I don't have LLVM -flto support set up on any of my machines at the moment. So this can be fixed by not using -flto at configure time, or by modifying configure scripts to use volatile. There is no linker or compiler fix to make here. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: "-flto -O2" shouln't opt out "undefined reference" error
On Tue, Jan 17, 2017 at 7:27 PM, Xuefer wrote: > volatile: i tried already with clang/llvm it worked. > > i'm using gentoo linux, trying to emerge everything with -flto. i'm not sure > if i understand linker/compiler bug or not a bug, i wonder how many script > is affected by this issue. OK, if you want everything compiled with -flto then you may need to fix some package configure scripts to make this work, and you may need autoconf fixes too. This may not be well tested. Exactly how lto integrates into a package build system may vary from package to package. For GCC, you can do --with-build-config=bootstrap-lto and it will bootstrap itself with LTO enabled. For most other packages though putting -flto in CFLAGS before configure/make is probably good enough. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: relocation information disappears
On 04/06/2017 04:20 AM, Katsuya TANAKA wrote: # ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -march=armv7-a -o w w.c ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-readelf -r w There is no "debug_f" symbol. Why not? The value of a weak symbol is evaluated at static link time. If a symbol is found, then that symbol address is used. If a symbol is not found, then the address is set to zero. In this testcase, there is no debug_f symbol, so the address is forced to zero at link time, and hence no relocs are necessary. # ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -march=armv7-a -o w2 w2.c There is a debug_info symbol. Variable is not good. In this case, debug_info is a function call, and function calls always go through the PLT, so there will be a PLT reloc for the function, even though we know the address is zero at link time. The address check however gets forced to zero, and has no relocs, because none is necessary. Note that weak symbols are not very useful with shared libraries. They are primarily intended for use with static linking. If you are trying to do something with a shared library, then don't use weak. Put a default definition of the symbol in the shared library, and then if you want to override it in the main program, just put a local definition in one of the source files linked into the main program. Jim ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
Re: FW: objdump says 'no recognized debugging informatio'
Ian Lance Taylor wrote: Sharath Manjunatha <[EMAIL PROTECTED]> writes: And I am using the object compiled with 345 compiler. I don't know what that compiler is. That would be a Cisco gcc-3.4.5 release with some patches. Not that it really matters. Sharath, you can use readelf -w (aka readelf --debug-dump) to look at DWARF2 debug info. This will be a large amount of info. Alternatively, you can use a command like "gcc -dA -S" to pretty-print DWARF2 debug info in the assembly file. Jim ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
