https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
Martin Liška changed:
What|Removed |Added
Known to fail||12.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #11 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:94c9b1bb79f63d000ebb05efc155c149325e332d
commit r13-6330-g94c9b1bb79f63d000ebb05efc155c149325e332d
Author: Martin Liska
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #10 from Martin Liška ---
I've filed an upstream review request:
https://reviews.llvm.org/D144424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #9 from Martin Liška ---
(In reply to Jakub Jelinek from comment #8)
> Sure, we want to keep using libbacktrace. But libbacktrace can be extended
> if Ian is ok with it, or some extensions can be done on the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #8 from Jakub Jelinek ---
Sure, we want to keep using libbacktrace. But libbacktrace can be extended if
Ian is ok with it, or some extensions can be done on the
libsanitizer/libbacktrace side of it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #7 from Martin Liška ---
So clang uses __sanitizer::LLVMSymbolizer:
$ clang jhead.i -fsanitize=address -g && strace -f -s512 ./a.out 2>&1 | grep
execv
execve("./a.out", ["./a.out"], 0x7fffd520 /* 116 vars */) = 0
[pid 5529]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #6 from Martin Liška ---
> so I wonder if emitting the locations isn't just wasted .rodata if libasan
> considers it being a windows_padding. In GCC 12 libsanitizer it was still
> location:
You are correct, we lost the ability to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #5 from Martin Liška ---
Thank you Jakub for the investigation. I'm saying yes, using symbol names from
debuginfo seems to me a nice improvement. Lemme take a look at it..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #4 from Jakub Jelinek ---
https://reviews.llvm.org/D127552
So I guess we need to look also if (and if not, why not) we get the same
symbolization from debug info and drop the location stuff there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #3 from Jakub Jelinek ---
This is in the arrays passed to __asan_{,un}register_globals.
Now, we emit
/* Build
struct __asan_global
{
const void *__beg;
uptr __size;
uptr __size_with_redzone;
const void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #2 from Martin Liška ---
So the module name is a string that is displayed when an ASAN error happens and
I see a discrepancy in between GCC and Clang (with LTO):
$ cat jhead.i
int x;
int *p;
int main() {
p =
*(p + 1) = 123;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #1 from Richard Biener ---
But those should be all generated early? Or if not by walking DECL_CONTEXT up
to the TRANSLATION_UNIT_DECL and from its location derive the filename.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
15 matches
Mail list logo
