From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug libdw/30967] Discriminator in Dwarf_Line_s may exceed 24 bits
Date: Thu, 26 Oct 2023 11:32:57 +0000 [thread overview]
Message-ID: <bug-30967-10460-Y9ExmeAJDq@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-30967-10460@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=30967
Mark Wielaard <mark at klomp dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |roland at gnu dot org
--- Comment #5 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Aleksei Vetrov from comment #4)
> (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
> > these discriminator codes can really be?
>
> For me it is ok to bump that bitfield, but there is a warning in the code:
>
> > All the flags and other bit fields should add up to 48 bits
> > to give the whole struct a nice round size.
>
> So this question should be directed to the author of this code: Roland
> McGrath <roland@redhat.com>. I think there may be slight performance/memory
> issues, but as a temporary solution it looks good.
Added Roland (now with another email address) to the CC.
Note that we have blown the size of this struct already to support the NVIDIA
extensions :{
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.
Another "solution"/workaround would be to just ignore such crazy big
discriminator values and just set them to zero or store them modulo 24 bits
(they are probably still unique then).
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2023-10-26 11:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 13:30 [Bug libdw/30967] New: " vvvvvv at google dot com
2023-10-12 14:12 ` [Bug libdw/30967] " vvvvvv at google dot com
2023-10-12 14:30 ` mark at klomp dot org
2023-10-25 15:47 ` fche at redhat dot com
2023-10-26 11:19 ` vvvvvv at google dot com
2023-10-26 11:32 ` mark at klomp dot org [this message]
2023-10-26 14:55 ` mark at klomp dot org
2023-10-26 15:12 ` fche at redhat dot com
2023-10-26 15:30 ` fche at redhat dot com
2023-10-26 15:37 ` vvvvvv at google dot com
2023-10-26 15:46 ` mark at klomp dot org
2023-10-26 15:47 ` fche at redhat dot com
2023-10-31 16:57 ` vvvvvv at google dot com
2023-10-31 23:19 ` mark at klomp dot org
2023-10-31 23:19 ` mark at klomp dot org
2023-11-07 19:01 ` vvvvvv at google dot com
2023-11-07 19:11 ` vvvvvv at google dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-30967-10460-Y9ExmeAJDq@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=elfutils-devel@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).