https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #15 from Aleksei Vetrov ---
Created attachment 15213
--> https://sourceware.org/bugzilla/attachment.cgi?id=15213&action=edit
logger_write.cpp
Attaching "logger_write.cpp" and a way to reproduce binary with big
discriminator with
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #14 from Aleksei Vetrov ---
Here are investigation results on why this happens in LLVM. It is a new
algorithm for assigning "hierarchical discriminator for FSAFDO".
>From https://reviews.llvm.org/D102246:
#define BASE_DIS_BIT_B
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
Mark Wielaard changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #13 from Mark Wielaard ---
(In reply to Aleksei Vetrov from comment #12)
> (In reply to Mark Wielaard from comment #6)
> > So my preferred workaround:
> > https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=really-large-dis
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #12 from Aleksei Vetrov ---
(In reply to Mark Wielaard from comment #6)
> So my preferred workaround:
> https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=really-large-disc
Do you have plan to merge it to master?
--
Yo
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #11 from Frank Ch. Eigler ---
> I'm more interested in this: what is worst that can happen on discriminator
> collision? We are not using discriminator at all in ABI monitoring, so I'm
> not familiar with its use cases.
That's a g
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #10 from Mark Wielaard ---
(In reply to Frank Ch. Eigler from comment #7)
> > So my preferred workaround:
>
> appears to be based on the assumption that truncated bitfields will not
> collide. Has this assumption been tested?
Mo
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #9 from Aleksei Vetrov ---
(In reply to Frank Ch. Eigler from comment #7)
> So my preferred workaround:
I like this workaround and it works in our use case.
> appears to be based on the assumption that truncated bitfields will no
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #8 from Frank Ch. Eigler ---
> The issue here is that we create (very) large arrays of struct Dwarf_Line_s
> and we do that eagerly, see bug #27405
> So we would like to keep that struct as small as possible.
Do we have an estimat
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #7 from Frank Ch. Eigler ---
> So my preferred workaround:
appears to be based on the assumption that truncated bitfields will not
collide. Has this assumption been tested?
--
You are receiving this mail because:
You are on the
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #6 from Mark Wielaard ---
So my preferred workaround:
diff --git a/libdw/dwarf_getsrclines.c b/libdw/dwarf_getsrclines.c
index df003c5f..69e10c7b 100644
--- a/libdw/dwarf_getsrclines.c
+++ b/libdw/dwarf_getsrclines.c
@@ -129,6 +12
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
Mark Wielaard changed:
What|Removed |Added
CC||roland at gnu dot org
--- Comment #5
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #4 from Aleksei Vetrov ---
(In reply to Frank Ch. Eigler from comment #3)
> Is there some reason not to just bump up that bitfield width from :24 to :32
> or more for now, until a deeper analysis of llvm informs us as to how wide
>
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #2
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
--- Comment #1 from Aleksei Vetrov ---
Created attachment 15166
--> https://sourceware.org/bugzilla/attachment.cgi?id=15166&action=edit
liblog.so
--
You are receiving this mail because:
You are on the CC list for the bug.
16 matches
Mail list logo