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 #13 from Jakub Jelinek 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 even close to what asan nee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #12 from H.J. Lu 2013-01-17 16:57:29
UTC ---
Size relocation means that all instances of
# __beg:
.quadcommon_data
# __size:
.quadcommon_data@size
# __size_with_redzone:
.quadcommon_data@size + 40
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #11 from Jakub Jelinek 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
non-common) var multiple t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #10 from H.J. Lu 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 about all the other t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #9 from Andrew Pinski 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 that asan now supports?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #8 from H.J. Lu 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
> R_X86_64_SIZE64 33
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #7 from H.J. Lu 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 word64 Z + A
They s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #6 from H.J. Lu 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 can do
.LASAN0:
# __b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #5 from Kostya Serebryany 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 this in both compilers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #4 from H.J. Lu 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", which resolve to original
ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #3 from Jakub Jelinek 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 those symbols. Not sure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739
--- Comment #2 from H.J. Lu 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 #1 from Jakub Jelinek 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, and
whether there will be
14 matches
Mail list logo
