public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
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.

  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).