https://open-source-silicon.dev
Join Slack
We don't build or test on mac due to hw availability. I know there are some users who make it work....
# openroad
m
We don't build or test on mac due to hw availability. I know there are some users who make it work. Can you reproduce it on Linux?
m
No, I can't.
I also don't have the HW 😕
m
It appears to be on selection of an item. Do you know what they are selecting when it happens?
m
Anywhere in the GUI. They actually recorded a video:
openlane_crash.mov
m
this is a clue; I'll see if I can come up with any guesses
m
Dumb question, but they just loaded the lib and the ODB. Is the LEF info included in the ODB?
m
yes
It is inspecting an sta object though so that's another clue as you don't have a Liberty in that case
(it still shouldn't crash)
m
Ohh they might have loaded the wrong liberty file
Yes, I bet that is it.
(maybe?)
ODB doesn't store any timing info does it? Or corner info?
m
no timing has to be reloaded separately
though it is true on all platforms
m
Yeah, I tried replicating with same corner lib etc. and it doesn't do it.
I see, it does have a Timing/Power view in the inspector which is just unpopulated if you don't load a lib and runtiming. (and the warning when you load an ODB)
I'll ask them to update timing before selecting something.
m
That's expected
m
Yeah
I'll see what happens if they update timing before selecting the instance. It seems they can do other things in the GUI before it crashes, but just selecting instances causes it.
d
This happens to me reliably, I have the hardware and I'm willing to tele-debug 🙂
m
A test case is to run SPM, and then just do this:
Copy code
opanroad -gui
>>> read_lib $env(PDK_ROOT)/sky130A/libs.ref/sky130_fd_sc_hd/lib/sky130_fd_sc_hd__ss_100C_1v60.lib
>>> read_db final/odb/spm.odb
Then select anything in the design with a left click.
a
@Matt Liberty Why can't the CI use the GitHub-provided M1 runners? Does it use too many cloud minutes?
m
@Austin Rovinski no way to debug any issues
The problem starts with the missing descriptor. I can see how downstream that would lead to a crash. I could make a narrow fix for the crash but many other places are similar. In general we assume the descriptor is found for anything that we display. What I can't see is why it is not found. We register all the descriptors in initialization so it must be that it isn't found when looking in
Copy code
std::unordered_map<std::type_index, std::unique_ptr<const Descriptor>>
      descriptors_;
this must be a mac specific failure to handle type_index lookup. They will not be able to see any timing data in the inspector even if it is loaded with this issue.
Any idea what compiler / os version?
I also don't know if other descriptors are affected
d
The compiler is LLVM (not Apple) Clang 16, OS version is macOS 15
Serious about my offer to jump on a debugging call- im available in like two hours or tomorrow
Whichever works for you
m
Today isn't great for me. Can you compare what Gui::registerDescriptor and Gui::getDescriptor are seeing for this sta::Instance*? Somehow we can't find what we store
d
Will do.
m
Should I open an issue on this?
m
@donn any progress?
d
Not yet. Picking it back up today
@Matt Liberty You called it… The sta:: elements values' type indices break. https://stackoverflow.com/a/75363998
Apparently, typeindex is just different across shared objects. This implies a visibility issue. I'll try to set visibility to default across both OpenSTA and OpenROAD…
Seems that [EDIT: libstdc++] has a workaround for this that [EDIT: libc++] doesn't because it's something of a hack. https://lists.llvm.org/pipermail/llvm-dev/2014-June/073465.html
🙌 1
@Matt Liberty I assume if you went and compiled OpenROAD and its dependencies on Linux with libc++ you'd run into the same issue, but I don't believe you'd care to repeat that. Bit stumped. Especially that SWIG, where sta::Instance is declared, doesn't support visibility and I'm assuming hashing demangled class names may make the UI a bit sluggish.
m
Are dynamic/shared libraries being used on mac?
does 
-rdynamic
help?
d
I think libQt is a dylib yes
m
I'm not sure how it would relate to sta::Instance*. Most of the comments in the items you pointed to refer to using -rdynamic so perhaps give that a try and see if it helps
d
I’ll try rdynamic when I get home
👍 1
Wrt Dylon’s I think it might be because it calls a libQt function which then calls back makeSelector
Dylibs even
m
Good hypothesis
d
Didn't appear to help sadly.
m
It seems this basic promise of the class is not properly supported in this situation. I don't know a better fix as it seems to be broken behavior in this library
This is why we don't support mac as I have no way to even try things
Its a bigger task but you could try using boost::typeindex::type_info and see if it is any better
d
sure, will report back when i try that
@Matt Liberty sigh so the problem now is std::any. std::any relies on std::type_info. which means there's no way to get runtime information from std::any with boost::type_index…
m
d
Working on PRs to backport 6743 to stable OpenLane and to update OpenROAD in dev OpenLane. Thank you for your patience @Matthew Guthaus
@Matthew Guthaus OpenLane 2.3.9 has been merged, which backports the fix. Please have your students upgrade, try it, and report back.
🙌 1
16 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by