[Bug gold/13850] New: init_array/fini_array sections are not in PT_GNU_RELRO as -z relro is given
http://sourceware.org/bugzilla/show_bug.cgi?id=13850
Bug #: 13850
Summary: init_array/fini_array sections are not in PT_GNU_RELRO
as -z relro is given
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
AssignedTo: i...@airs.com
ReportedBy: petec...@gmail.com
CC: ccout...@google.com
Classification: Unclassified
Hi,
Recently I'm studying RELRO and find that compared to gnu ld, gold produces a
different result (e.g., .init_array section did not go into PT_GNU_RELRO as
linking with -z relro).
In the following diff, please find the condition, "&& type ==
elfcpp::SHT_PROGBITS", that causes the different behavior.
Looks like this condition is not necessary (or should be moved into an inner
"if").
Any comment?
diff --git a/gold/layout.cc b/gold/layout.cc
index a4ef31a..13f7ea1 100644
--- a/gold/layout.cc
+++ b/gold/layout.cc
@@ -1368,29 +1368,28 @@ Layout::make_output_section(const char* name,
elfcpp::Elf_Word type,
else if (is_prefix_of(".fini_array", name))
type = elfcpp::SHT_FINI_ARRAY;
}
// FIXME: const_cast is ugly.
Target* target = const_cast(¶meters->target());
os = target->make_output_section(name, type, flags);
}
// With -z relro, we have to recognize the special sections by name.
// There is no other way.
bool is_relro_local = false;
if (!this->script_options_->saw_sections_clause()
&& parameters->options().relro()
- && type == elfcpp::SHT_PROGBITS
&& (flags & elfcpp::SHF_ALLOC) != 0
&& (flags & elfcpp::SHF_WRITE) != 0)
{
if (strcmp(name, ".data.rel.ro") == 0)
is_relro = true;
else if (strcmp(name, ".data.rel.ro.local") == 0)
{
is_relro = true;
is_relro_local = true;
}
else if (type == elfcpp::SHT_INIT_ARRAY
|| type == elfcpp::SHT_FINI_ARRAY
|| type == elfcpp::SHT_PREINIT_ARRAY)
is_relro = true;
-
Thanks,
Pete
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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 gold/15200] New: Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 Bug #: 15200 Summary: Runtime undefined reference to __exidx_start/_end Product: binutils Version: 2.24 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gold AssignedTo: i...@airs.com ReportedBy: petec...@gmail.com CC: ccout...@google.com Classification: Unclassified Created attachment 6896 --> http://sourceware.org/bugzilla/attachment.cgi?id=6896 Android plasma test case We should be able to define a symbol in output even if there is already a definition in dso, e.g., we should use local exidx in output but not in a certaion dso. Attached please find a Android test case and also a possible patch to fix this problem. The issue is also reproducible by using gold linker to link against libraries in Android ndk-r8. = REPRODUCE STEP = $ readelf -rs plasma.o | grep exidx ... 0590 9c1a R_ARM_GOT_BREL __exidx_end 0594 9d1a R_ARM_GOT_BREL __exidx_start ... 154: 0 NOTYPE WEAK DEFAULT UND __gnu_Unwind_Find_exidx 156: 0 NOTYPE GLOBAL DEFAULT UND __exidx_end 157: 0 NOTYPE GLOBAL DEFAULT UND __exidx_start $ readelf -s libc.so | grep exidx 103: c82c 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end 322: c82c 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start 707: 84e820 FUNCGLOBAL DEFAULT4 __gnu_Unwind_Find_exidx 115: c82c 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end 334: c82c 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start 719: 84e820 FUNCGLOBAL DEFAULT4 __gnu_Unwind_Find_exidx $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so $ readelf -rs libplasma.so | grep exidx 40a4 1a15 R_ARM_GLOB_DAT __exidx_end 40a8 1b15 R_ARM_GLOB_DAT __exidx_start 25: 0 FUNCWEAK DEFAULT UND __gnu_Unwind_Find_exidx 26: 0 NOTYPE GLOBAL DEFAULT UND __exidx_end 27: 0 NOTYPE GLOBAL DEFAULT UND __exidx_start 120: 0 FUNCWEAK DEFAULT UND __gnu_Unwind_Find_exidx 121: 0 NOTYPE GLOBAL DEFAULT UND __exidx_end 122: 0 NOTYPE GLOBAL DEFAULT UND __exidx_start -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #1 from pete 2013-02-26 03:51:18 UTC --- Created attachment 6897 --> http://sourceware.org/bugzilla/attachment.cgi?id=6897 Android libc.so -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #2 from pete 2013-02-26 03:52:31 UTC --- Created attachment 6898 --> http://sourceware.org/bugzilla/attachment.cgi?id=6898 a possible fix -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #3 from pete 2013-03-07 02:39:59 UTC --- Hello, Let me describe this issue again. The runtime undefined reference is because: 1. Using ld.gold to link against libraries (say libc.so) in android ndk-r8, and those libraries are probably generated by ld.bfd. $ readelf -s /tmp/android-ndk-r8/platforms/android-14/arch-arm/usr/lib/libc.so | grep exidx 106: cf44 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end 334: cf44 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start 730: 89a820 FUNCGLOBAL DEFAULT4 __gnu_Unwind_Find_exidx 118: cf44 0 NOTYPE GLOBAL DEFAULT ABS __exidx_end 346: cf44 0 NOTYPE GLOBAL DEFAULT ABS __exidx_start 742: 89a820 FUNCGLOBAL DEFAULT4 __gnu_Unwind_Find_exidx 2. Running the library on a newer version (say 4.2) of Android system, and there are no __exidx_start/_end symbols in the libraries, e.g, libc.so. $ readelf -s $AOSP/out/target/product/generic/system/lib/libc.so | grep exidx 882: e929 4 FUNCGLOBAL DEFAULT7 __gnu_Unwind_Find_exidx 891: 0 FUNCGLOBAL DEFAULT UND dl_unwind_find_exidx So, it's fine to generate dynamic relocations for undefined symbols, but I think section/segment symbols in output probably should be defined locally anyway, if we're going to define them. Using section/segment definition in DT_NEEDED doesn't seem to be the correct behavior? BTW, I also checked ld.bfd also defines __exidx_start/_end locally. $ arm-linux-androideabi-ld.bfd -shared -o libplasma.so plasma.o libc.so $ readelf -s libplasma.so | grep exidx 3: 3980 0 NOTYPE LOCAL DEFAULT ABS __exidx_end 4: 3858 0 NOTYPE LOCAL DEFAULT ABS __exidx_start 64: 0 FUNCWEAK DEFAULT UND __gnu_Unwind_Find_exidx 119: 3980 0 NOTYPE LOCAL DEFAULT ABS __exidx_end 121: 3858 0 NOTYPE LOCAL DEFAULT ABS __exidx_start 185: 0 FUNCWEAK DEFAULT UND __gnu_Unwind_Find_exidx Any comment about the issue and the patch? - Thanks, Pete -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #5 from pete 2013-03-07 05:31:25 UTC --- (In reply to comment #4) > The symbols __exidx_end & __exidx_start were exported incorrectly in > the past. This is fixed in both ld & gold in the sense that these > symbols are defined by not exported. I think defining these symbols > when there is a non-weak definition in a DSO is not the right thing to > do. This is basically multiple definition and usually is an error. If so, all section/segment symbols should be defined (if needed) by not exported? But when there is a non-weak definition in a DSO, it's still possible to find ld.gold define and export segment symbols like __bss_start (See gold.defstd.cc:214. only_if_ref is set to false). And there is no multiple definition error. $ readelf -Ds libc.so | grep __bss_start 268 311: d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__ 619 470: d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so $ readelf -s libplasma.so | grep __bss_start 73: 4148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 168: 4148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > I am not working on the Android NDK so I can't give you a good > suggestion here. Does using the latest NDK fixes your problem? > Yes, there is no this issue with the latest NDK. - Thanks, Pete -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #7 from pete 2013-03-07 06:43:08 UTC --- I can think visibility does matter, but only for exporting the symbol or not. In the previous case, gold does define the __bss symbols but not use the definition in DSO, so I think we should still define section/segment symbols locally. -Pete (In reply to comment #6) > The symbols do not have same visibility. gold in general is > compatible with GNU ld. If you look at src/ld/emulparams/, you will > set that the __bss symbols are exported but the __exidx symbols are > defined hidden. gold matches the behaviour of ld. If you look at > defstd.cc in gold, you will again see that some of these symbols are > hidden but some are not. > > -Doug > > > On Wed, Mar 6, 2013 at 9:31 PM, petechou at gmail dot com > wrote: > > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > > > > --- Comment #5 from pete 2013-03-07 05:31:25 > > UTC --- > > (In reply to comment #4) > >> The symbols __exidx_end & __exidx_start were exported incorrectly in > >> the past. This is fixed in both ld & gold in the sense that these > >> symbols are defined by not exported. I think defining these symbols > >> when there is a non-weak definition in a DSO is not the right thing to > >> do. This is basically multiple definition and usually is an error. > > > > If so, all section/segment symbols should be defined (if needed) by not > > exported? > > > > But when there is a non-weak definition in a DSO, it's still possible to > > find > > ld.gold define and export segment symbols like __bss_start (See > > gold.defstd.cc:214. only_if_ref is set to false). And there is no multiple > > definition error. > > > > $ readelf -Ds libc.so | grep __bss_start > > 268 311: d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__ > > 619 470: d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > > > > $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so > > > > $ readelf -s libplasma.so | grep __bss_start > > 73: 4148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > >168: 4148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > > > >> I am not working on the Android NDK so I can't give you a good > >> suggestion here. Does using the latest NDK fixes your problem? > >> > > > > Yes, there is no this issue with the latest NDK. > > > > - > > Thanks, > > Pete > > > > -- > > Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email > > --- You are receiving this mail because: --- > > You are on the CC list for the bug. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #9 from pete 2013-03-13 02:03:32 UTC --- If there is a libfoo.so, it's possible to implement part of functions in libfoo.so and then link against libfoo.so again to produce a new library. I think the "linker-defined" symbols should also have higher priority than the symbols in DSO. And I also think we should have the same behavior on defining symbol value whether only_if_ref is set or not? The patch will affect 4 ways to define output symbols: 1. do_define_in_output_data 2. do_define_in_output_segment 3. do_define_as_constant 4. add_undefined_symbol_from_command_line For 1, 2, and 3, it makes sense to use the given output section, segment, and constant to define symbol values if the "linker-defined" symbols have higher priority. As for 4, I think it doesn't matter. - Thanks, Pete (In reply to comment #8) > Hi Pete, > > 1. My concern of your patch is that it affects all targets, not just > ARM. While it may fix the problem on ARM, I cannot speak for authors > of other backends. > 2. I am don't have power approve a patch, you need to convince Ian > Taylor that this is the right thing to do for all targets. > 3. This bug only happens when DSOs incorrectly export __exidx_start & > __exidx_end. These DSOs are considered broken and I strongly > recommend you moving to a newer NDK version with DSOs that have proper > visibility. Both ld & gold no longer export these symbols. The > reason for not exporting is explained here in the ld patch: > > http://sourceware.org/ml/binutils/2009-11/msg00367.html > > -Doug > > > On Wed, Mar 6, 2013 at 10:43 PM, petechou at gmail dot com > wrote: > > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > > > > --- Comment #7 from pete 2013-03-07 06:43:08 > > UTC --- > > I can think visibility does matter, but only for exporting the symbol or > > not. > > In the previous case, gold does define the __bss symbols but not use the > > definition in DSO, so I think we should still define section/segment symbols > > locally. > > > > -Pete > > > > (In reply to comment #6) > >> The symbols do not have same visibility. gold in general is > >> compatible with GNU ld. If you look at src/ld/emulparams/, you will > >> set that the __bss symbols are exported but the __exidx symbols are > >> defined hidden. gold matches the behaviour of ld. If you look at > >> defstd.cc in gold, you will again see that some of these symbols are > >> hidden but some are not. > >> > >> -Doug > >> > >> > >> On Wed, Mar 6, 2013 at 9:31 PM, petechou at gmail dot com > >> wrote: > >> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > >> > > >> > --- Comment #5 from pete 2013-03-07 05:31:25 > >> > UTC --- > >> > (In reply to comment #4) > >> >> The symbols __exidx_end & __exidx_start were exported incorrectly in > >> >> the past. This is fixed in both ld & gold in the sense that these > >> >> symbols are defined by not exported. I think defining these symbols > >> >> when there is a non-weak definition in a DSO is not the right thing to > >> >> do. This is basically multiple definition and usually is an error. > >> > > >> > If so, all section/segment symbols should be defined (if needed) by not > >> > exported? > >> > > >> > But when there is a non-weak definition in a DSO, it's still possible to > >> > find > >> > ld.gold define and export segment symbols like __bss_start (See > >> > gold.defstd.cc:214. only_if_ref is set to false). And there is no > >> > multiple > >> > definition error. > >> > > >> > $ readelf -Ds libc.so | grep __bss_start > >> > 268 311: d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start__ > >> > 619 470: d898 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > >> > > >> > $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so > >> > > >> > $ readelf -s libplasma.so | grep __bss_start > >> > 73: 4148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > >> >168: 4148 0 NOTYPE GLOBAL DEFAULT ABS __bss_start > >> > > >> >> I am not working on the Android NDK so I can't give you a good > >> >> suggestion here. Does using the latest NDK fixes your problem? > >> >> > >> > > >> > Yes, there is no this issue with the latest NDK. > >> > > >> > - > >> > Thanks, > >> > Pete > >> > > >> > -- > >> > Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email > >> > --- You are receiving this mail because: --- > >> > You are on the CC list for the bug. > > > > -- > > Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email > > --- You are receiving this mail because: --- > > You are on the CC list for the bug. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #11 from pete 2013-03-20 02:04:21 UTC --- Hello Ian, Would you please comment on the issue and patch? - Thanks, Pete (In reply to comment #10) > I have no object to what is proposed but the decision is Ian's. > > On Tue, Mar 12, 2013 at 7:03 PM, petechou at gmail dot com > wrote: > > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > > > > --- Comment #9 from pete 2013-03-13 02:03:32 > > UTC --- > > If there is a libfoo.so, it's possible to implement part of functions in > > libfoo.so and then link against libfoo.so again to produce a new library. I > > think the "linker-defined" symbols should also have higher priority than the > > symbols in DSO. > > > > And I also think we should have the same behavior on defining symbol value > > whether only_if_ref is set or not? > > > > The patch will affect 4 ways to define output symbols: > > 1. do_define_in_output_data > > 2. do_define_in_output_segment > > 3. do_define_as_constant > > 4. add_undefined_symbol_from_command_line > > > > For 1, 2, and 3, it makes sense to use the given output section, segment, > > and > > constant to define symbol values if the "linker-defined" symbols have higher > > priority. > > > > As for 4, I think it doesn't matter. > > > > - > > Thanks, > > Pete > > > > (In reply to comment #8) > >> Hi Pete, > >> > >> 1. My concern of your patch is that it affects all targets, not just > >> ARM. While it may fix the problem on ARM, I cannot speak for authors > >> of other backends. > >> 2. I am don't have power approve a patch, you need to convince Ian > >> Taylor that this is the right thing to do for all targets. > >> 3. This bug only happens when DSOs incorrectly export __exidx_start & > >> __exidx_end. These DSOs are considered broken and I strongly > >> recommend you moving to a newer NDK version with DSOs that have proper > >> visibility. Both ld & gold no longer export these symbols. The > >> reason for not exporting is explained here in the ld patch: > >> > >> http://sourceware.org/ml/binutils/2009-11/msg00367.html > >> > >> -Doug > >> > >> > >> On Wed, Mar 6, 2013 at 10:43 PM, petechou at gmail dot com > >> wrote: > >> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > >> > > >> > --- Comment #7 from pete 2013-03-07 06:43:08 > >> > UTC --- > >> > I can think visibility does matter, but only for exporting the symbol or > >> > not. > >> > In the previous case, gold does define the __bss symbols but not use the > >> > definition in DSO, so I think we should still define section/segment > >> > symbols > >> > locally. > >> > > >> > -Pete > >> > > >> > (In reply to comment #6) > >> >> The symbols do not have same visibility. gold in general is > >> >> compatible with GNU ld. If you look at src/ld/emulparams/, you will > >> >> set that the __bss symbols are exported but the __exidx symbols are > >> >> defined hidden. gold matches the behaviour of ld. If you look at > >> >> defstd.cc in gold, you will again see that some of these symbols are > >> >> hidden but some are not. > >> >> > >> >> -Doug > >> >> > >> >> > >> >> On Wed, Mar 6, 2013 at 9:31 PM, petechou at gmail dot com > >> >> wrote: > >> >> > http://sourceware.org/bugzilla/show_bug.cgi?id=15200 > >> >> > > >> >> > --- Comment #5 from pete 2013-03-07 > >> >> > 05:31:25 UTC --- > >> >> > (In reply to comment #4) > >> >> >> The symbols __exidx_end & __exidx_start were exported incorrectly in > >> >> >> the past. This is fixed in both ld & gold in the sense that these > >> >> >> symbols are defined by not exported. I think defining these symbols > >> >> >> when there is a non-weak definition in a DSO is not the right thing > >> >> >> to > >> >> >> do. This is basically multiple definition and usually is an error. > >> >> > > >> >> > If so, all section/segment symbols should be defined (if needed) by > >> >> > not > >> >> > exported? >
[Bug gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #16 from pete 2013-03-20 05:38:56 UTC --- (In reply to comment #15) > I think that is what my patch does. Did I get it wrong? I'm thinking the patch does the same thing as mine. I have 2 questions: 1. in_reg() and in_dyn() seem to be mutual exclusive? 2. is it possible to see in_dyn() and is_from_dynobj() return different truth values for a symbol? Did I misunderstand something? > > I think it probably makes sense in general to create an only_if_ref > linker-defined symbol if there is a ref in the regular objects and a > definition > in a shared object. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #17 from pete 2013-03-20 05:54:20 UTC --- (In reply to comment #16) > (In reply to comment #15) > > I think that is what my patch does. Did I get it wrong? And we should return NULL if oldsym->in_reg() is true instead? if (oldsym == NULL) return NULL; if (oldsym->source() == Symbol::IS_UNDEFINED) ; else if (oldsym->in_reg()) return NULL; else if (oldsym->is_from_dynobj()) ; else return NULL; > > I'm thinking the patch does the same thing as mine. > > I have 2 questions: > 1. in_reg() and in_dyn() seem to be mutual exclusive? > 2. is it possible to see in_dyn() and is_from_dynobj() return different truth > values for a symbol? > Did I misunderstand something? > > > > > I think it probably makes sense in general to create an only_if_ref > > linker-defined symbol if there is a ref in the regular objects and a > > definition > > in a shared object. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #18 from pete 2013-03-20 06:20:57 UTC --- Sorry! Yours is correct. Forget about this. (In reply to comment #17) > > And we should return NULL if oldsym->in_reg() is true instead? > > if (oldsym == NULL) > return NULL; > if (oldsym->source() == Symbol::IS_UNDEFINED) > ; > else if (oldsym->in_reg()) > return NULL; > else if (oldsym->is_from_dynobj()) > ; > else > return NULL; > -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #20 from pete 2013-03-21 05:05:21 UTC --- (In reply to comment #19) > The in_reg() and in_dyn() functions are not mutually exclusive. Both will > return true if a symbol appears in both a regular object and a dynamic object. I think your patch probably should be changed to if (oldsym == NULL) return NULL; if (oldsym->source() == Symbol::IS_UNDEFINED) ; else if (oldsym->is_from_dynobj()) ; else if (oldsym->in_reg()) return NULL; else return NULL; Or maybe we don't need to check in_reg()/in_dyn() at all? Then the code could be like if (oldsym == NULL) return NULL; if (oldsym->source() != Symbol::IS_UNDEFINED && !oldsym->is_from_dynobj()) return NULL; This would check if there is a reference and a definition in dynobj as well. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #22 from pete 2013-03-25 03:56:32 UTC --- (In reply to comment #21) > I don't see why either of your suggested changes would be correct. > > Would you mind trying my patch, the second one in comment #13, to see if it > fixes your problem? Yes, it can define the symbols correctly. > > Thanks. Is the in_reg() checking for the reference in regular object? If so, will it be more clear if we can check it first? like if (oldsym == NULL || !oldsym->in_reg()) return NULL; if (oldsym->source() != Symbol::IS_UNDEFINED && !oldsym->is_from_dynobj()) return NULL; Well, this is only my opinion. Another question about the only_if_ref flag. Is it for the reference in regular object? Looks like both reg/dyn symbols will go into the namepool, but we don't check in_reg() previously. Thanks. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gold/15200] Runtime undefined reference to __exidx_start/_end
http://sourceware.org/bugzilla/show_bug.cgi?id=15200 --- Comment #23 from pete 2013-03-26 08:01:28 UTC --- Created attachment 6949 --> http://sourceware.org/bugzilla/attachment.cgi?id=6949 Android libc.so w/o __exidx_start/end Hello Ian, I find one issue with the patch in comment #13: Unable to define exidx section symbols in output data when linking the attached libc.so w/o __exidx_start/end, and there is a reference to the undefined exidx symbol in regular object. We probably should still check symbol->is_undefined() instead. Symbol::IS_UNDEFINED only covers the undefined symbols from command line (-u option). Then, the code would be if (oldsym == NULL) return NULL; if (oldsym->is_undefined()) ; else if (!oldsym->in_reg()) return NULL; else if (oldsym->is_from_dynobj()) ; else return NULL; Or if (oldsym == NULL || !oldsym->in_reg()) return NULL; if (!oldsym->is_undefined() && !oldsym->is_from_dynobj()) return NULL; Please let me know your comment. Thanks. = REPRODUCE STEP = $ readelf -rs plasma.o | grep exidx ... 0590 9c1a R_ARM_GOT_BREL __exidx_end 0594 9d1a R_ARM_GOT_BREL __exidx_start ... 154: 0 NOTYPE WEAK DEFAULT UND __gnu_Unwind_Find_exidx 156: 0 NOTYPE GLOBAL DEFAULT UND __exidx_end 157: 0 NOTYPE GLOBAL DEFAULT UND __exidx_start $ readelf -s libc.so | grep exidx 74: 8b7820 FUNCGLOBAL DEFAULT4 __gnu_Unwind_Find_exidx 78: 8b7820 FUNCGLOBAL DEFAULT4 __gnu_Unwind_Find_exidx $ arm-linux-androideabi-ld.gold -shared -o libplasma.so plasma.o libc.so $ readelf -rs libplasma.so | grep exidx 409c 1a15 R_ARM_GLOB_DAT __exidx_end 40a0 1b15 R_ARM_GLOB_DAT __exidx_start 25: 0 FUNCWEAK DEFAULT UND __gnu_Unwind_Find_exidx 26: 0 NOTYPE GLOBAL DEFAULT UND __exidx_end 27: 0 NOTYPE GLOBAL DEFAULT UND __exidx_start 120: 0 FUNCWEAK DEFAULT UND __gnu_Unwind_Find_exidx 121: 0 NOTYPE GLOBAL DEFAULT UND __exidx_end 122: 0 NOTYPE GLOBAL DEFAULT UND __exidx_start -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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
