This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Mon, 2003-11-10 at 02:02, Alan Modra wrote: > On Sun, Nov 09, 2003 at 05:42:26PM +0200, Martin Schlemmer wrote: > > http://sources.redhat.com/ml/binutils/2003-11/msg00069.html > > http://sources.redhat.com/ml/binutils/2003-11/msg00077.html > > http://sources.redhat.com/ml/binutils/2003-11/msg00082.html > > > > from Alan Modra breaks sparc - basically ld quits all the time > > (even with simple helloworld.c) with SIGBUS signal. > > > > If you want the specific one, we can try to track it further. > > It can't be the last two, they only touch ppc. sparc or sparc64? sparc64 (64bit kernel, 32bit userland) > I'm a bit surprised my patch broke anything, as I didn't make it in a > hurry, and ran the binutils testsuite for most of the affected > architectures. sparc-linux and sparc64-linux were among the targets > tested. Do you have local patches to any of the files listed in the > first ChangeLog? > The one for Jakub (can drop it if not needed anymore ?) attached, and your tls-section-alignment.patch. > When reporting problems about gas and ld, it's useful to provide a > testcase that triggers the problem. In the case of a gas problem, we > want input files to gas and command line switches used. The inputs to > gas are _not_ .c or .i files, but rather .s files. If your original > source was a C program, you can generate the .s file and see the command > line options by passing -v -save-temps to gcc in addition to all the > usual options you use. The reason we don't want C files is that we > might not have a C compiler around for the target you use. While it > might be possible to build a compiler, that takes considerable time and > disk space, and we might not end up with exactly the same compiler you > use. > > In the case of a ld problem, the input files are .o, .a and .so files, > and possibly a linker script specified with -T. Again, when using gcc > to link, you can see these files by adding options to the gcc command > line. Use -v -save-temps -Wl,-t, except that on targets that use gcc's > collect2, you would add -v -save-temps -Wl,-t,-debug. The -t option > tells ld to print all files and libraries used, so that, for example, > you can associate -lc on the ld command line with the actual libc used. > Note that your simple two line C program to trigger a problem typically > expands into several megabytes of objects by the time you include > libraries. It is antisocial to post megabyte sized attachments to > mailing lists, so please put large ld testcases somewhere on an ftp or > web site so that only interested developers need to download them, or > offer to email them on request. Better still, try to reduce the > testcase to not use system libraries. Jason do you think you can merge binutils-2.14.90.0.7-r2 again, and include above ? Thanks, -- Martin Schlemmer
2002-04-20 Jakub Jelinek <jakub@redhat.com> * elf32-sparc.c (elf32_sparc_relocate_section): Find real output section with SEC_MERGE. * elf64-sparc.c (sparc64_elf_relocate_section): Likewise. --- bfd/elf32-sparc.c.jj Thu Feb 6 08:07:10 2003 +++ bfd/elf32-sparc.c Thu Feb 6 08:31:54 2003 @@ -2168,7 +2168,7 @@ elf32_sparc_relocate_section (output_bfd struct elf_link_hash_entry *h; Elf_Internal_Sym *sym; asection *sec; - bfd_vma relocation, off; + bfd_vma relocation, off, orig_addend = 0; bfd_reloc_status_type r; bfd_boolean is_plt = FALSE; bfd_boolean unresolved_reloc; @@ -2196,6 +2196,7 @@ elf32_sparc_relocate_section (output_bfd { sym = local_syms + r_symndx; sec = local_sections[r_symndx]; + orig_addend = rel->r_addend; relocation = _bfd_elf_rela_local_sym (output_bfd, sym, sec, rel); } else @@ -2525,6 +2526,24 @@ elf32_sparc_relocate_section (output_bfd asection *osec; osec = sec->output_section; + /* FIXME: As soon as making sections zero size + is possible, this if can go away. */ + if (bfd_is_abs_section (osec) + && h == NULL + && (sec->flags & SEC_MERGE) + && ELF_ST_TYPE (sym->st_info) == STT_SECTION + && sec->sec_info_type == ELF_INFO_TYPE_MERGE) + { + asection *msec; + + msec = sec; + _bfd_merged_section_offset (output_bfd, &msec, + elf_section_data (sec)->sec_info, + sym->st_value + orig_addend, + (bfd_vma) 0); + osec = msec->output_section; + } + indx = elf_section_data (osec)->dynindx; /* FIXME: we really should be able to link non-pic --- bfd/elf64-sparc.c.jj Thu Feb 6 08:07:10 2003 +++ bfd/elf64-sparc.c Thu Feb 6 08:31:54 2003 @@ -2016,7 +2016,7 @@ sparc64_elf_relocate_section (output_bfd struct elf_link_hash_entry *h; Elf_Internal_Sym *sym; asection *sec; - bfd_vma relocation, off; + bfd_vma relocation, off, orig_addend = 0; bfd_reloc_status_type r; bfd_boolean is_plt = FALSE; bfd_boolean unresolved_reloc; @@ -2039,6 +2039,7 @@ sparc64_elf_relocate_section (output_bfd { sym = local_syms + r_symndx; sec = local_sections[r_symndx]; + orig_addend = rel->r_addend; relocation = _bfd_elf_rela_local_sym (output_bfd, sym, sec, rel); } else @@ -2267,6 +2268,24 @@ sparc64_elf_relocate_section (output_bfd asection *osec; osec = sec->output_section; + /* FIXME: As soon as making sections zero size + is possible, this if can go away. */ + if (bfd_is_abs_section (osec) + && h == NULL + && (sec->flags & SEC_MERGE) + && ELF_ST_TYPE (sym->st_info) == STT_SECTION + && sec->sec_info_type == ELF_INFO_TYPE_MERGE) + { + asection *msec; + + msec = sec; + _bfd_merged_section_offset (output_bfd, &msec, + elf_section_data (sec)->sec_info, + sym->st_value + orig_addend, + (bfd_vma) 0); + osec = msec->output_section; + } + indx = elf_section_data (osec)->dynindx; /* We are turning this relocation into one
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |