Fix writability of 1_synth.sdc

[hzeller]

The 1_synth.sdc is copied from a template from the bazel input files, which are read-only. The exec cp then will copy the file which then is still read-only, thus the subsequent write will fail.

Make the file writable.

(this was discovered attempting to run in an RBE environment where the readonlyness of the inputs is very strict).

[gemini-code-assist]

Code Review

This pull request introduces a new patch, 0036-fix-sdc-readonly.patch, which ensures that the target SDC file is writable before attempting to write to it in synth_odb.tcl. The review feedback suggests using Tcl's built-in file attributes command instead of spawning an external chmod process to improve efficiency and portability.

[gemini-code-assist]

Using exec chmod spawns an external process, which is less efficient and less portable than using Tcl's built-in file attributes command. Consider using file attributes -permissions u+w instead.

+catch {file attributes $::env(RESULTS_DIR)/1_synth.sdc -permissions u+w}

[hzeller]

This is just to fix the build, I am leaving this tweak up to @oharboe when he applies the fix upstream.

[maliberty]

I don't see any downside to this change

[hzeller]

@oharboe looks good ?

[oharboe]

@oharboe looks good ?

It makes no sense to me.

Show the exact steps where this is a problem?

Why is this needed or useful and why is it not a much broader problem?

[hzeller]

If you run the following test for instance:

bazel test -c opt //test/orfs/gcd:gcd_idempotent_test_cts

... and look at the log, you see that the 1_synth.sdc file is initially created by copying from the source directory

exec cp test/orfs/gcd/constraint.sdc bazel-out/k8-opt/bin/test/orfs/gcd/results/asap7/gcd/b/1_synth.sdc

... and then later attempted to be overwritten.

Of course, the original source-code is not writable, and it fact it is coming from a read-only filesystem when compiling in an RBE environment, so there is no write-bit on the input file. When copying, the non-set write bit is retained, and now we have a 1_synth.sdc file in the output that is read-only.
Later, the tcl-file attempts to open the very same file for writing and fails.

This is why we have to set the write-bit. Maybe there is something wrong in the logic and the first sdc file should never have been written, but I leave that test logic question to you. All i needed to make the test work is to make sure that the write call then can succeed.

The above-mentioned test is one of them, but since this code is used in other tests, about 25 tests fail to build on an RBE (and accidentally work when compiling locally).

[oharboe]

@hzeller You're using the ORFS idempotency tests I made 🥳

I'll have a look at this...

[oharboe]

I see what is going on... Fix coming up...

This PR should be closed, it is trying to treat a symptom of the underlying problem.

[hzeller]

Closing, awaiting proper fix.

[oharboe]

@hzeller Root cause found: 1_synth.sdc had two writers. yosys' synth.tcl copies the user's SDC_FILE into place (a leftover from before SDC canonicalization existed), then synth_odb.tcl overwrites it in place with the OpenSTA-canonicalized version. cp preserves mode bits, so with RBE's read-only inputs the copy is read-only and the second write fails — locally it only accidentally works.

Proper fix is up as The-OpenROAD-Project/bazel-orfs#754: the yosys stage no longer produces 1_synth.sdc at all (its output is 1_2_yosys.sdc, the raw copy); synth_odb.tcl/synth_syn.tcl are the sole writers, carried as a bazel-orfs patch until the same fix lands in ORFS. It also stops bazel-orfs from touch-stubbing missing primary artifacts, so this class of problem fails the action immediately instead of surfacing as read-only/empty files downstream.

Once that merges, bazelisk run @bazel-orfs//:bump here picks it up — no chmod needed, so I'll close this PR in favor of that.

[oharboe]

The bump PR is up: #10823 (bazel-orfs pinned to the PR head ahead of its merge). bazelisk test //test/orfs/gcd/... passes 9/9 locally — @hzeller, if you get a chance, that branch should be directly testable on your RBE setup.