debugging tools for *nix platforms

[staticfloat]

This has been sitting in one of my topic branches for a while, they're a few debugging tools that it might be useful to have sitting around in base.

• Sys.shlib_list() iterates through the shared libraries linked into our current process, returning a list of their paths. Useful when you're not sure what dlopen() is picking up.
• Also adds in some simple logic to get some info about the CPU we're running on beyond whether it's 32 or 64-bit.

[staticfloat]

Note that there's no windows stuff in here not out of malice, but simple ignorance and lack of familiarity.

[staticfloat]

EDIT: I just noticed that there is already a cpu_info() function in base. I wonder how long that's been there.... I'm editing this PR really quick to get rid of the duplicated code.

[staticfloat]

Man, that CPUinfo struct is really neat. Thanks to whoever put that together! Okay, I've removed my CPU stuff, and now just use Sys.cpu_info() to get the model. I print that out by default now, as I think it's been playing an important role in bug reports recently.

[pao]

Thanks to whoever put that together!

blame says @vtjnash https://github.com/JuliaLang/julia/blame/231fd4f6dc654fde571bae3b0ec83df07c0b0822/base/sysinfo.jl

[vtjnash]

Can you factor out a function Sys.dlpath(::Union(Ptr{Void}, String))?

I'm fine with merging this without windows support -- I'll add that in later (it should be easy, so it doesn't need to hold this up)

(for reference, EnumerateLoadedModules64 is similar to shlib_list, and the code for converting to paths is in Tk.jl/src/tkwidget.jl::init()

[staticfloat]

the code for converting to paths is in Tk.jl/src/tkwidget.jl::init()

I assume you're referring to the call to GetModuleFileNameA. I'm unaware of any analogue on OSX or Linux; I have only been able to find functions to enumerate over all the modules linked into a process. My implementation of dlpath() would then be a filter wrapped around shlib_list(). If you know of an alternative, I'd be happy to hear it.

[ViralBShah]

Is this ready to be merged? Should we document Sys.shlib_list()?

[staticfloat]

Yes, we should probably document it. I'm waiting to see what Jameson has in mind for Sys.dlpath().

[vtjnash]

Sorry, somehow I missed staticfloat's reply last week. A filter around shlib_list() is also fine. Would dladdr also do the right thing?

Can you open an issue against windows when you merge this that someone / I needs to add the code to do this on windows?

[vtjnash]

#5045 essentially implements Sys.dlpath, if it was generalized

[staticfloat]

I saw that, but I would need a symbol from the library, not the handle to
the library itself. Perhaps I should write something that can enumerate
symbols from a handle, and then hook that up to dladdr....

On Dec 7, 2013 10:59 AM, "Jameson Nash" [email protected] wrote:

#5045 essentially implements Sys.dlpath, if it was generalized

—
Reply to this email directly or view it on GitHub.

[tknopp]

I could generalize the function I have wrote to

jl_get_dll_path_from_symbol(void* symbol)

Under windows one might be able to pass the handle of LoadLibrary to this, which would allow for implementing

l_get_dll_path_from_dll_name(char* name)

[staticfloat]

Alright! I've managed to (with the help of some wonderful people on SO) write a dlpath implementation on Linux and OSX. Comments welcome. I've rebased and everything works on my OSX and Linux machines, so I'm thinking this is ready to merge soon.

[vtjnash]

missing a dlclose?

[staticfloat]

Ah, yes. Thank you. Fixed in 47915f3

[StefanKarpinski]

I would love to make the naming more consistent. How about all the dynamic library related things start with dl? So this would be sh_ext => dlext and sh_list to dllist, etc.

[staticfloat]

I agree. I'll open a PR since this will be a breaking change.