public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Evgeny Vereshchagin <evvers@ya.ru>
Cc: elfutils-devel@sourceware.org
Subject: Re: [PATCH v3] build: allow turning off --no-undefined and -z,defs
Date: Sun, 5 Dec 2021 16:50:16 +0100	[thread overview]
Message-ID: <YazfuJiwqO8BlFSp@wildebeest.org> (raw)
In-Reply-To: <20211203180209.987784-1-evvers@ya.ru>

Hi Evgeny,

I really appreciate you helping us using more analyzers and fuzzers to
improve the code base. I think the address sanitizer already helped
improve the code. But it would help if you replied to the original
reviews and/or mentioned how the different versions of your patch have
changed since the last time. As far as I can see you only changed the
commit message a little this time.

On Fri, Dec 03, 2021 at 06:02:09PM +0000, Evgeny Vereshchagin wrote:
> Other than that, while options like --enable-sanitize-undefined are
> helpful shortcuts, they simply can't cover all the usecases and it's
> still necessary to pass additional compiler flags to clang via
> CFLAGS to for example get around issues like
> https://github.com/evverx/elfutils/issues/16 and
> https://github.com/evverx/elfutils/issues/15.

I really do believe that working from the now proposed
--enable-sanatize-address will be easiest to integrate address
sanitizer support. See how I used it to workaround isssues with the
gcc address sanitizer. You can use it likewise to work around issues
with clang. e.g. the configure check should detect the issue with
--no-undefined and could try if adding -lasan to LDFLAGS helps.

So the other isssues you are seeing with the clang address sanitizer
is "applying non-zero offset ... to null pointer" and "variable length
array bound evaluates to non-positive value 0". I am not sure how
those are actual problems. In the first case the calculated addresses
aren't actually used as (dereferenced) pointers, in the second the
array bound being zero also means the array content isn't used. Do you
know why these issues are flagged? Are there any extra ASAN_OPTIONS
set in these cases?

Cheers,

Mark


  reply	other threads:[~2021-12-05 15:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-03  5:37 [PATCH] " Evgeny Vereshchagin
2021-12-04 13:03 ` Florian Weimer
2021-12-03 14:17   ` [PATCH v2] " Evgeny Vereshchagin
2021-12-04 20:26     ` Mark Wielaard
2021-12-03 18:02       ` [PATCH v3] " Evgeny Vereshchagin
2021-12-05 15:50         ` Mark Wielaard [this message]
2021-12-05 16:52           ` Evgeny Vereshchagin
2021-12-08 15:29             ` Mark Wielaard
2021-12-08 19:15               ` Evgeny Vereshchagin

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=YazfuJiwqO8BlFSp@wildebeest.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=evvers@ya.ru \
    /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).