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:
Unabl
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
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #21 from Ian Lance Taylor 2013-03-24 22:26:50
UTC ---
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?
Thanks.
--
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 th
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #19 from Ian Lance Taylor 2013-03-20 12:27:58
UTC ---
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.
--
Configure bugmail:
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;
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 (o
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
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #15 from Ian Lance Taylor 2013-03-20 04:44:36
UTC ---
I think that is what my patch does. Did I get it wrong?
I think it probably makes sense in general to create an only_if_ref
linker-defined symbol if there is a ref in the regu
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #14 from Doug Kwan 2013-03-20 04:41:03
UTC ---
The special symbols in question __exidx_{start,end} were exported from
DSO's by mistake in both ld & gold and the mistake has been fixed in
both linkers. We really don't want referenc
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #13 from Ian Lance Taylor 2013-03-20 03:32:47
UTC ---
oldsym->in_dyn() will return true if the symbol was seen in a dynamic object.
I don't see why we should create the symbol if it is seen in a dynamic object.
It seems that the
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #12 from Ian Lance Taylor 2013-03-20 03:29:49
UTC ---
oldsym->in_dyn() will return true if the symbol was seen in a dynamic object.
I don't see why we should create the symbol if it is seen in a dynamic object.
It seems that the
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
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #10 from Doug Kwan 2013-03-13 03:57:35
UTC ---
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=152
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
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #8 from Doug Kwan 2013-03-07 08:10:16
UTC ---
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 hav
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
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #6 from Doug Kwan 2013-03-07 05:42:20
UTC ---
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
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 n
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
--- Comment #4 from Doug Kwan 2013-03-07 04:04:35
UTC ---
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 def
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 prob
http://sourceware.org/bugzilla/show_bug.cgi?id=15200
Ian Lance Taylor changed:
What|Removed |Added
CC||dougkwan at google dot com
--
Conf
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 a
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
24 matches
Mail list logo
