All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Cain <bcain@quicinc.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Michael Lambert <mlambert@quicinc.com>,
	Sid Manning <sidneym@quicinc.com>
Subject: hexagon sysemu - library loading path feature
Date: Thu, 17 Dec 2020 05:14:20 +0000	[thread overview]
Message-ID: <SN6PR02MB420590EF08DD9FFA5DC81EB6B8C60@SN6PR02MB4205.namprd02.prod.outlook.com> (raw)

My team is working on sysemu support for Hexagon.  We've made some good progress so far and we'll work on upstreaming after Taylor’s hexagon linux-user patch series lands.

The only use case we have focused on with sysemu is booting/running elf programs.  Both "-device loader,file=..." or "-kernel" are effective and work similarly.  We have implemented "angel calls" (semihosting) to do host I/O.  We have not yet tried using the QEMU semihosting features/cmdline args, but may explore that option.

One feature we'd like to integrate is a guest library search path feature.  The existing hexagon simulator program distributed in the Hexagon SDK has a command line option, “--usefs".  The manual states that it “Cause[s] the simulator to search for files in the directory with the specified path. It is used for accessing shared object files that are loaded during program execution.”  If the guest OS has a loader that tries to resolve an executable or library's DT_NEEDED shared object libraries, we would want QEMU angel calls to be able to search a user specified host-path for the toolchain language support libraries.

This feature is like the functionality in QEMU’s “QEMU_LD_PREFIX” environment variable used by linux-userspace.  So, one idea was to just (ab)use this interface to mean the same thing for sysemu.  We could make it a target-specific hexagon feature, if it doesn’t make sense to have it as target-independent.  And if it makes sense we could qualify it like HEXAGON_QEMU_LD_PREFIX.

If not this environment variable, is there an existing QEMU feature that maps well here?  Or is there a better interface that we should consider instead?

-Brian


             reply	other threads:[~2020-12-17  5:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17  5:14 Brian Cain [this message]
2021-01-22 17:45 ` hexagon sysemu - library loading path feature Philippe Mathieu-Daudé
2021-02-16 11:17   ` Alex Bennée
2021-02-19  0:15     ` Brian Cain

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=SN6PR02MB420590EF08DD9FFA5DC81EB6B8C60@SN6PR02MB4205.namprd02.prod.outlook.com \
    --to=bcain@quicinc.com \
    --cc=mlambert@quicinc.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sidneym@quicinc.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.