https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:40:48
UTC ---
(In reply to comment #7)
There are already
R_386_SIZE32 38 word32 Z + A
R_X86_64_SIZE32 32 word32 Z + A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-17
16:43:46 UTC ---
(In reply to comment #8)
Their support has been checked into glibc and binutils.
Can address sanitizer use them?
What about all the other targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:48:53
UTC ---
(In reply to comment #9)
(In reply to comment #8)
Their support has been checked into glibc and binutils.
Can address sanitizer use them?
What
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17
16:49:58 UTC ---
Ugh, no, that is way too premature. This really shouldn't be a dynamic
relocation. And asan shouldn't be registering the same (common or in the end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:57:29
UTC ---
Size relocation means that all instances of
# __beg:
.quadcommon_data
# __size:
.quadcommon_data@size
# __size_with_redzone:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17
17:48:18 UTC ---
No idea why you keep mentioning
.quadcommon_data
.quadcommon_data@size
.quadcommon_data@size + 40
That is nothing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2013-01-14 22:11:16
UTC ---
Created attachment 29165
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29165
A prototype
If as, ld and ld.so provide size info via symbol@size, we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2013-01-15 02:19:55
UTC ---
There are already
R_386_SIZE32 38 word32 Z + A
R_X86_64_SIZE32 32 word32 Z + A
R_X86_64_SIZE64 33
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-21
09:46:41 UTC ---
Just for the record:
llvm implementation of asan does not catch these either for the same reason.
It would be interesting to find a way to implement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-19
13:26:34 UTC ---
That is not a bug, it can't. Asan needs to insert padding after it, but you
don't know if the symbol will be defined by the current CU, or some other,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-12-19 13:42:12
UTC ---
If upper address or size of the common symbol is
available to ASAN at compile time as a special
symbol generated by assembler/linker, will it
help?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-19
13:49:35 UTC ---
That would look like too big hack.
Perhaps we could emit the common symbols as .bss .weak objects with padding,
and register as global a local alias to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-12-19 16:58:34
UTC ---
The symbol size is always available at link-time or run-time.
We just never find a use for it in program itself. We can add
relocations for foo@BOUND,
14 matches
Mail list logo
