public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
To: Milian Wolff <>,
Subject: Re: runtime validation of DT_SYMTAB lookups - why is there no DT_SYMSZ?
Date: Thu, 28 Jul 2022 18:41:27 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <2563495.X3S6A8DOgW@milian-workstation>

Hi Milian,

On Wed, 2022-07-27 at 13:38 +0200, Milian Wolff wrote:
> Thanks for confirming that this isn't available currently. Would it
> be 
> possible to add this? What's the process for standardization here? I guess it 
> would take a very long time, yet this seems to me as if it would be beneficial 
> in the long term.

Standardization of the ELF gabi takes place on (sorry google groups, I
know, sigh): you should be able
to subscribe with so you don't
have to go through the webgui mess.

There is also but that is more for GNU
extensions and I think you want something generic.

> > Di Chen recently
> > (or actually not that recently, I just still haven't reviewed,
> > sorry!)
> > posted a patch for
> > to print out
> > the
> > symbols from the dynamic segment
> >
> Interesting. But from what I can tell, this patch has access to the
> full Elf 
> object and thus can access segments which are not normally loaded at
> runtime?

Yes it could, but it doesn't use anything that isn't referenced from
the phdrs or dynamic segment, so it only uses those parts that are
normally loaded at runtime. If you go through the dynamic segment then
everything it references (.dynsym in this case) is from a loaded
segment. So going through phdrs to check where it is loaded and the
length is fine.

> Try with eu-elflint --gnu which suppresses some known issues.
> Indeed, with `--gnu` the tool reports `No errors`.
> > Also could you show those symbol values (1272, 3684, 25720, 27227)
> > they
> > might have a special type, so their st_value isn't really an
> > address?
> ```
> $ eu-readelf -s | grep -E
> "^\s*(1272|3684|25720|27227):"
>  1272: 003f9974      0 NOTYPE  GLOBAL DEFAULT       25
> __bss_start__@@Qt_5
>  3684: 003f9974      0 NOTYPE  GLOBAL DEFAULT       25
> __bss_start@@Qt_5
>  1272: 003ccc4c      0 NOTYPE  LOCAL  DEFAULT       17 $d
>  3684: 003cbfec      0 NOTYPE  LOCAL  DEFAULT       17 $d
> 25720: 003f9974      0 NOTYPE  GLOBAL DEFAULT       25 __bss_start
> 27227: 003f9974      0 NOTYPE  GLOBAL DEFAULT       25 __bss_start__
> ```
> The first two matches come from the `.dynsym`, the last four come
> from 
> `.symtab`.
> Can anyone tell me how `eu-readelf` resolves these symbol names?

Currently through the section tables, which point to the string table
section used. But Di Chen's patch would change that by going through
the dynamic segment and phdrs to find the strtab for the dynsym segment
(but will of course still need to go through the sections for the
.symtab symbols since those aren't accessible through the phdrs).



  reply	other threads:[~2022-07-28 16:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-11 16:40 Milian Wolff
2022-07-26 15:28 ` Mark Wielaard
2022-07-27 11:38   ` Milian Wolff
2022-07-28 16:41     ` Mark Wielaard [this message]
2022-08-28  6:41       ` Jacob Burkholder

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

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