Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional support for symbol table dump and module address/size info on POSIX systems (adds GNU extension dependence) #1205

Open
skliper opened this issue Jan 11, 2022 · 6 comments
Milestone

Comments

@skliper
Copy link
Contributor

skliper commented Jan 11, 2022

Is your feature request related to a problem? Please describe.
Currently checksum app does not work on systems that use os-impl-posix-dl-symtab.c since module address/size data is not filled in, nor is OS_SymbolTableDump supported.

Describe the solution you'd like
Would add GNU extension dependence, but dl_iterate_phdr() could be used to get the information required for both symbol table dump and module address/size. Example for getting module address here: https://stackoverflow.com/questions/19451791/get-loaded-address-of-a-elf-binary-dlopen-is-not-working-as-expected

Describe alternatives you've considered
None

Additional context
We've avoided GNU extension dependence, but if supported on the desired system it would be helpful to have the option for this functionality to work. Another use case is when simulating a system that does have these functions implemented, it's likely desirable to support the capability.

Requester Info
Jacob Hageman - NASA/GSFC

@skliper
Copy link
Contributor Author

skliper commented Jan 12, 2022

Updated suggestion - Add OS_NotifyEvent OS_EVENT_READ_MODULE_INFO and OS_EVENT_DUMP_SYMBOL_TABLE or similar and put the platform specific logic in the PSP.

@skliper skliper assigned ghost Jan 25, 2022
@skliper
Copy link
Contributor Author

skliper commented Jan 25, 2022

Added @acudmore to help with RTEMS approach/concept. Although the OSAL impact is probably the same (add the OS_NotifyEvent calls and fix in the PSP).

@astrogeco
Copy link
Contributor

@ghost
Copy link

ghost commented Mar 1, 2022

I started reviewing the existing code and OS_NotifyEvent framework.

For RTEMS, with Eric's pull request (#1221 ) we have a complete os-impl-loader.c
To complete RTEMS support, we need to create an RTEMS specific os-impl-symtab.c, since I believe the code will be RTEMS specific and will not work with POSIX calls. I don't think it will make sense to use OS_NotifyEvent calls to the PSP, since this code should work on all RTEMS targets, and would have to be duplicated in all RTEMS based PSPs.
There is an RTEMS shell command that dumps all symbols to the console, so I can use it as a base for the implementation.

I still have to look at POSIX.

@ghost
Copy link

ghost commented Mar 1, 2022

@dmknutsen suggested using these two tools

https://www.mankier.com/1p/nm https://docs.rtems.org/releases/4.5.1-pre3/toolsdoc/binutils-2.10-docs/binutils/binutils00002.html

Definitely useful on the host, I use them all of the time to dump the symbols from executable images, but I don't think these will work on the targets. Nice tools to be familiar with though!

@skliper
Copy link
Contributor Author

skliper commented Mar 7, 2022

I think the OS_NotifyEvent call to the PSP was specific to the linux implementation since the recommended calls are not POSIX, but GNU extensions that we tend to avoid in OSAL.

jphickey pushed a commit to jphickey/osal that referenced this issue Aug 10, 2022
…dates

 nasa#1205: Added task and CDS file write default filenames
 nasa#1131: Removed optional from EVS log
 nasa#1127: Non-parameter reload/restart doesn't increment cmd error
 nasa#1029: Removed system log elements from reset preservation list
 nasa#942: Simplifed table partial load file requirement
jphickey pushed a commit to jphickey/osal that referenced this issue Aug 10, 2022
@skliper skliper added this to the Equuleus milestone Dec 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants