[Bug ld/21705] ld disappears up own butt never to return (a curious case?)
https://sourceware.org/bugzilla/show_bug.cgi?id=21705 --- Comment #3 from Alan Modra --- With regard to Y_UP, you may be in trouble due to compiling without optimization. See https://sourceware.org/ml/binutils/2012-12/msg00088.html for example, where I'm being schooled about this. (I only pretend to be a C++ programmer.) You also might not understand the way archives behave with GNU ld and other unix linkers. Object files are only extracted to satisfy undefined references at the point the archive is searched. A reference from a later object file, perhaps from another archive, won't cause the earlier object to be extracted. You can change that by enclosing archives on the command line with --start-group --end-group. See the ld documentation. -- 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/21700] powerpc-ibm-aix6.1.0.0 fails with unresolved symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21700
James Reynolds changed:
What|Removed |Added
CC||james.reynolds at cristie dot
com
--- Comment #2 from James Reynolds ---
Created attachment 10241
--> https://sourceware.org/bugzilla/attachment.cgi?id=10241&action=edit
Compiled assembly and CC files
(In reply to Alan Modra from comment #1)
> Please attach the assembly file giving this error, and the resuling object
> file produced by IBM as.
>
> The patch you propose is just hiding a problem, perhaps with gcc. Most
> relocation formats, including xcoff I believe, don't support relocations
> with two or more symbols.
Yes, you are indeed correct, I get an error later with:
ld-new: .libs/compatibility.o: loader reloc in read-only section .text
The attached file contains the *.cc file that comes from the pre-processing
stage, the assembler output of compiling that (on an AIX box) and the result of
compiling that using IBM as and using gnu as and my misguided patch.
The errors from this file are:
compatibility.s: Assembler messages:
compatibility.s:959: Error: can't resolve `_compatibility.rw_[RW]' {.data
section} - `__gcc_unwind_dbase' {*UND* section}
compatibility.s:1330: Error: can't resolve `_compatibility.rw_[RW]' {.data
section} - `__gcc_unwind_dbase' {*UND* section}
compatibility.s:1389: Error: can't resolve `_compatibility.rw_[RW]' {.data
section} - `__gcc_unwind_dbase' {*UND* section}
--
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
some problem about libbfd
When I'm using libbfd(bfd.h), I met some problems.
I wrote a simple file(test.cpp) and compiled it successfully. Then I ran
'objdump test' and I got all infomation(etc. sections syms) correctly.
I installed binutils on my server, and built a check_test.cpp just like what
objdump.c do. When I ran './check_test test', I got the section Info correctly
but I coundn't get other info(even bfd_get_filename (abfd) and abfd->format are
null).
I have checked my code many times and i cannot find bug, so I guess maybe my
compiling option were not right.
I use 'g++ -g check_test.cpp /usr/lib64/libbfd.a /usr/lib64/libiberty.a -ldl
-lz -o check_test' or 'g++ -g check_test.cpp -lbfd -liberty -ldl -lz -o
check_test', and the problem was same as before.
So I want to know how to compile a cpp using bfd? What else should I know to
use libbfd?
The attachment is my code.
Yours Sincerely.#include
#include "config.h"
#include
#include
#include
void
list_matching_formats (char **p)
{
printf ("Matching formats:");
while (*p)
printf (" %s", *p++);
printf("\n");
}
static void
dump_bfd (bfd *abfd) {
asymbol **sy = NULL;
long storage;
int symcount;
if(abfd->xvec == NULL) {
printf("bfd hasn't xvec\n");
}
else {
printf ("%s: file format\n", bfd_get_filename (abfd));
}
if (!(bfd_get_file_flags (abfd) & HAS_SYMS))
{
printf("bfd hasn't syms\n");
printf("bfd->flags %x\n", abfd->flags);
symcount = 0;
//return;
}
storage = bfd_get_symtab_upper_bound (abfd);
if(storage < 0) {
printf("failed to read symbol table\n");
}
if (storage)
sy = (asymbol **) malloc (storage);
symcount = bfd_canonicalize_symtab (abfd, sy);
}
static void
display_object_bfd (bfd *abfd) {
char **matching;
if (bfd_check_format_matches (abfd, bfd_object, &matching))
{
printf("bfd object\n");
dump_bfd (abfd);
return;
}
if (bfd_get_error () == bfd_error_file_ambiguously_recognized)
{
printf("bfd error file_ambiguously_recognized\n");
list_matching_formats (matching);
free (matching);
return;
}
if (bfd_get_error () != bfd_error_file_not_recognized)
{
printf("bfd error not file_not_recognized\n");
return;
}
if (bfd_check_format_matches (abfd, bfd_core, &matching))
{
printf("bfd core\n");
dump_bfd (abfd);
return;
}
if (bfd_get_error () == bfd_error_file_ambiguously_recognized)
{
printf("bfd error file_ambiguously_recognized\n");
list_matching_formats (matching);
free (matching);
}
}
int main(int argc, char *argv[]) {
if (argc<2) return -1;
char *filename = argv[1];
char **matching;
bfd_init();
bfd *mybfd = bfd_openr(filename, NULL);
if(mybfd == NULL) {
printf("bfd NULL\n");
}
else {
if (bfd_check_format (mybfd, bfd_archive)) {
printf("bfd archive\n");
}
else {
printf("bfd not archive\n");
printf("bfd format: %s\n", mybfd->format);
display_object_bfd(mybfd);
}
// if (!bfd_check_format_matches(mybfd, bfd_object, &matching)) {
// printf("bfd_check_format wrong\n");
// }
// else {
// printf("bfd format %s\n", bfd_get_format(mybfd));
// printf("bfd target %s\n", bfd_get_target(mybfd));
// int sections_count = bfd_count_sections(mybfd);
// printf("bfd section num: %d \n", sections_count);
// {
//asection *psection = bfd_get_section_by_name(ibfd,
".debug_info");
//printf("section name=%s; start_address=0x%llx; size=%d\n"
//, psection->name
//, psection->vma
//, psection->size);
// }
// int syms_count = bfd_get_symcount(mybfd);
// printf("bfd symbols num: %d \n", syms_count);
// bfd_get_symtab_upper_bound(mybfd);
// printf("bfd symbols storage: %ld \n", storage);
// if(storage < 0) exit(0);
// asymbol **syms;
// long number_of_symbols;
// syms = (asymbol **)malloc(storage);
// number_of_symbols = bfd_canonicalize_symtab (ibfd, syms);
// printf("Scanning %ld symbols\n", number_of_symbols);
//}
}
printf("last line\n");
fflush(stdout);
bfd_close(mybfd);
return 0;
}
//g++ -g check_toy.cpp /usr/lib64/libbfd.a /usr/lib64/libiberty.a -ldl -lz -o
check_toy___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/21703] The first symbol definition is overwritten by second definition when --allow-multiple-definition is provieded
https://sourceware.org/bugzilla/show_bug.cgi?id=21703 --- Comment #2 from Renlin Li --- (In reply to Alan Modra from comment #1) > When you say "the first definition is from the library", I assume you're > talking about a shared library. If so, a later definition for the same > symbol in a regular object file should replace the shared library > definition. That's the way ELF shared libraries are supposed to work. > _bfd_elf_merge_symbol ought to twiddle the symbol to undefined (or new) so > that the generic linker will accept the newly seen regular object file > definition. The result ought to be the same as when then regular object > file definition is seen first. In that case a later shared library > definition is ignored. > > Whether --allow-multiple-definition is given or not should not affect symbol > resolution, just whether an error is reported, as it would be for example > when linking two regular object files each with a definition of the same > symbol. I agree for shared library case. The behavior I observed here is happening in arm-none-eabi toolchain with static newlib. -- 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 ld/21705] ld disappears up own butt never to return (a curious case?)
https://sourceware.org/bugzilla/show_bug.cgi?id=21705 --- Comment #4 from Mick Pearson --- Thanks Alan, I know this isn't exactly a help desk; but I hope there are others here who might help me. A problem I run into is almost all talk about "undefined reference" diagnostics devolves into, "you need to put the -lx options after the -o option." I can't really test the shared library that links to verify that it works. But I just find it funny that it builds and the executable does not, and has so many of these undefined reference diagnostics that should logically plague the shared library also, but don't. It's frustrating because everything is done by the book and the commands are right there to see, and it's all legit and even when I pull out the suspect large-object component I still see these "undefined reference" diagnostics pretty much for everything. I would think that ld is not finding the project's libraries but they are there in the output, as in the case of Y_UP. (Which might require an external definition under C++98; but -std=gnu++11 is used. And -O1 was used across the board in this build also.) I don't understand why this doesn't just work. If everyone has this kind of difficulty the GNU developer community must be tired of fielding calls for help :) -- 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 ld/21705] ld disappears up own butt never to return (a curious case?)
https://sourceware.org/bugzilla/show_bug.cgi?id=21705 --- Comment #5 from Mick Pearson --- EDITED: I solved the truly confusing problems by moving the main (shared library) in the link order to be behind the executable components. (I think the GNU community would be wise to circle the linker back if doesn't find a reference in the regular order.) I had thought about the relationship of the executable's components in this regard based on some things I read but I had not factored the core library into those considerations. The biggest trouble I'm having now is that the big .o file defines the vtables of classes that the component .a files use. I tried both moving the .o to after the .a and copying it so it's before -o and after the .a without success... I suppose either there is a special option for this, or to satisfy GNU/ld it must be artificially packaged as a .a file. There is absolutely no harm in ld looking in every .o and .a if it can't find what it's looking for in the historical order. Microsoft's linker does so, and it seems to me like order should only be important in edge case; that you're not doing anyone any favor like this (I certainly don't appreciate the extra effort I must make and losing a day's work contemplating this.) -- 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 ld/21703] The first symbol definition is overwritten by second definition when --allow-multiple-definition is provieded
https://sourceware.org/bugzilla/show_bug.cgi?id=21703 --- Comment #3 from Renlin Li --- Created attachment 10242 --> https://sourceware.org/bugzilla/attachment.cgi?id=10242&action=edit foo_arm.c -- 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 ld/21703] The first symbol definition is overwritten by second definition when --allow-multiple-definition is provieded
https://sourceware.org/bugzilla/show_bug.cgi?id=21703 --- Comment #4 from Renlin Li --- Created attachment 10243 --> https://sourceware.org/bugzilla/attachment.cgi?id=10243&action=edit foo_thumb.c -- 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 ld/21703] The first symbol definition is overwritten by second definition when --allow-multiple-definition is provieded
https://sourceware.org/bugzilla/show_bug.cgi?id=21703 --- Comment #5 from Renlin Li --- Created attachment 10244 --> https://sourceware.org/bugzilla/attachment.cgi?id=10244&action=edit main_arm.c -- 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 ld/21703] The first symbol definition is overwritten by second definition when --allow-multiple-definition is provieded
https://sourceware.org/bugzilla/show_bug.cgi?id=21703 --- Comment #6 from Renlin Li --- I create a test case to show the bug. arm-none-eabi-gcc main_arm.c -O2 -march=armv7-a -mfloat-abi=softfp -specs=aprofile-validation.specs -c -o main_arm.o arm-none-eabi-gcc -O2 -mthumb -march=armv7-a -mfloat-abi=softfp -specs=aprofile-validation.specs -c foo_arm.c -o foo_arm.o arm-none-eabi-gcc -O2 -mthumb -march=armv7-a -mfloat-abi=softfp -specs=aprofile-validation.specs -c foo_thumb.c -o foo_thumb.o arm-none-eabi-gcc main_arm.o foo_thumb.o foo_arm.o -specs=aprofile-validation.specs -o main.exe -Wl,--allow-multiple-definition In this case, we would expect in main.exe, the function get called is the thumb version, and BLX is used to do the function call. But BL is used to call the thumb function. I have checked weak symbol and dynamic symbol are properly handled. -- 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 ld/21703] The first symbol definition is overwritten by second definition when --allow-multiple-definition is provieded
https://sourceware.org/bugzilla/show_bug.cgi?id=21703 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-05 Ever confirmed|0 |1 --- Comment #7 from Alan Modra --- I had a quick look at your example (typo on foo_arm.c command line, you don't want -mthumb there!), and while I don't know the arm backend that well, I think the problem is due to target_internal being set from the last definition seen. -- 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 ld/21705] ld disappears up own butt never to return (a curious case?)
https://sourceware.org/bugzilla/show_bug.cgi?id=21705 --- Comment #6 from Mick Pearson --- /bin/ranlib: libcolladadom3D-big-obj.a(viewer_base.lite.cpp.o): warning: COMDAT symbol '.rdata$_ZTVN12ColladaDOM_34DAEP9ElementalINS_9Collada0825__cg_param_group__float__ENS0_7ElementEEE' does not match section name '.xdata$_ZN12ColladaDOM_39Collada0526__cg_param_type__half1x4__D0Ev' I don't know if this is at the root of my problems or not; but I've been through a lot with my unique circumstances. I thought that GCC's strictures are instantiating vtables were my most likely issue. I could not think of a foolproof way around them, and I could not find precise documentation, so I started by using the preprocessor to generate a single CPP file, so I could be sure GCC would emit everything. I've had to play around with that, until I believe the linker finished with all of the inputs one time, but the components were not finding the virtual methods. They seemed to want the method itself instead of a vtable. (They were in a position to not use the vtable.) So I rebuilt to try to externalize the virtual methods they wanted. And now I get this error. It looks like a bug. The two names are completely mismatched. This is not when linking the executable, but simply when building this object or putting it into a single object archive (The archive isn't really necessary, but I am right now leaving nothing to chance until everything works.) P.S. Unless the one time things worked it was a fluke because of a hollow archive or something, I think what really made the linker go forever was a template class that had a static method with a local-static object inside of it. It's not really a situation where every variation can be enumerated so I changed it to a global static procedure local to the translation-unit. -- 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/21700] powerpc-ibm-aix6.1.0.0 fails with unresolved symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=21700 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-05 Ever confirmed|0 |1 --- Comment #3 from Alan Modra --- OK, so the AIX assembler emits two relocations for the expression, R_POS_64 against _compatibility.rw_, and R_NEG against __gcc_unwind_dbase. The GNU assembler would need to do the same. grep for RELOC_EXPANSION_POSSIBLE to get an idea of how to do this. Be warned that the GNU XCOFF support has not been maintained for a long time, and wasn't that good to start with. -- 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 ld/21705] ld disappears up own butt never to return (a curious case?)
https://sourceware.org/bugzilla/show_bug.cgi?id=21705 Mick Pearson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Mick Pearson --- (In reply to Mick Pearson from comment #6) > /bin/ranlib: libcolladadom3D-big-obj.a(viewer_base.lite.cpp.o): warning: > COMDAT symbol > '. > rdata$_ZTVN12ColladaDOM_34DAEP9ElementalINS_9Collada0825__cg_param_group__flo > at__ENS0_7ElementEEE' does not match section name > '.xdata$_ZN12ColladaDOM_39Collada0526__cg_param_type__half1x4__D0Ev' > Left without recourse I checked to see if Cygwin had some alternative packages or something. It offered 2.28 above the default (2.25) and GCC up to versions 6 (from 4 abouts) and doing so made this error go away. And also made the program build and run. It will take me a while to tease apart what did what, but it's safe to close this. I think maybe the Cygwin group could stand to be alerted to a possible need to bump the binutils default version offering up. Thanks for humoring me :) -- 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
