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.

Sign up for GitHub

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

Jump to bottom

The latest version does some funkyness. #2

Open
ianamason opened this issue Apr 18, 2018 · 1 comment
Open

The latest version does some funkyness. #2

ianamason opened this issue Apr 18, 2018 · 1 comment

Comments

@ianamason
Copy link
Member

ianamason commented Apr 18, 2018 •
edited
Loading

Both extract-bc and get-bc seem to be fooled by the build process.

Warning: Failed to find the file /vagrant/musllvm/obj/src/ldso/.dlopen.o.bc

because it isn't called o but rather lo:

 ls -la obj/src/ldso/.dlopen*
-rw-r--r-- 1 vagrant vagrant 1868 Apr 18 13:25 obj/src/ldso/.dlopen.lo.bc

Not sure why lo and o are different (in the reverse way):

ls -la obj/src/ldso/dlopen*
-rw-r--r-- 1 vagrant vagrant 1424 Apr 18 13:25 obj/src/ldso/dlopen.lo
-rw-r--r-- 1 vagrant vagrant 1392 Apr 18 13:23 obj/src/ldso/dlopen.o
@JL2210
Copy link

JL2210 commented Feb 4, 2019

The reason is that *.lo files are Libtool object files, whereas *.o files are ELF/PE/Mach-O object files.
*.lo files are plain text documents that provide some info for the object file.

ianamason pushed a commit that referenced this issue Jul 3, 2019
@kunkku @richfelker
fix race condition in file locking
0db393d 
The condition occurs when
- thread #1 is holding the lock
- thread #2 is waiting for it on __futexwait
- thread #1 is about to release the lock and performs a_swap
- thread #3 enters the __lockfile function and manages to grab the lock
  before thread #1 calls __wake, resetting the MAYBE_WAITERS flag
- thread #1 calls __wake
- thread #2 wakes up but goes again to __futexwait as the lock is
  held by thread #3
- thread #3 releases the lock but does not call __wake as the
  MAYBE_WAITERS flag is not set

This condition results in thread #2 not being woken up. This patch fixes
the problem by making the woken up thread ensure that the flag is
properly set before going to sleep again.

Mainainer's note: This fixes a regression introduced in commit
c21f750.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ianamason @JL2210