[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hexagon sysemu - library loading path feature

From: Philippe Mathieu-Daudé
Subject: Re: hexagon sysemu - library loading path feature
Date: Fri, 22 Jan 2021 18:45:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

Cc'ing Laurent and Alex.

On 12/17/20 6:14 AM, Brian Cain wrote:
> 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 
> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]