http://bugs.winehq.org/show_bug.cgi?id=22384
Summary: DbgHelp doesn't support DWARF-2 on Mac OS X Product: Wine Version: 1.1.42 Platform: x86 OS/Version: Mac OS X 10.6 Status: UNCONFIRMED Severity: minor Priority: P2 Component: dbghelp AssignedTo: wine-bugs@winehq.org ReportedBy: cdavis@mines.edu
Mac OS X has long had support for DWARF-2. Unfortunately, the current implementation of DWARF-2 support in DbgHelp is tied to ELF. This means it can't directly be used on Mac OS X, because Mac OS X does not support ELF.
I understand that getting things to work on Linux first takes priority over getting them to work on Mac OS, but right now we Mac users are stuck with the inferior stabs format. Plus, I get the feeling we're going to need this for 64-bit support. Also, DWARF happens to be the default format on 10.5 and up.
I also understand that the scheme that Apple uses is different from ELF systems. Not only does DWARF-2 stuff get its own segment (__DWARF), but when the binary is built, the DWARF stuff is put into a dSYM companion bundle. On top of that, the dSYM bundle isn't even generated automatically for multi-file builds. This means that:
- We have to invoke dsymutil to create the dSYM bundle. - We have to install the dSYM bundle (if present) with each binary. - We have to find the dSYM bundle to get DWARF-2 debug info.
I would be more than willing to help with this. (This might have even made a good SoC project. Too late now...)
http://bugs.winehq.org/show_bug.cgi?id=22384
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |eric.pouech@orange.fr Ever Confirmed|0 |1
--- Comment #1 from Eric Pouech eric.pouech@orange.fr 2010-04-17 02:01:41 --- some comments: #1 dwarf2 support is not tied to ELF, it now works in PE files as well (for mingw support) #2 I've recently added an abstraction layer (image_* functions) in order to cope with such situations #3 I don't know lots of the Mac OS-X image file format, but there's alread stabs support for Mac OS-X in dbghelp, so I would expect the compiler chain (when generating either dwarf or stabs) would just put this info in different segments/sections/whatever the name is #4 you may also ping ken Thomases who wrote the stabs support for Mac OS-X
so I'd start to check whether the can extend the image_* abstraction layer to support mac osx files (and debug segments) A+
http://bugs.winehq.org/show_bug.cgi?id=22384
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@codeweavers.com
--- Comment #2 from Ken Thomases ken@codeweavers.com 2010-04-19 17:10:23 --- (In reply to comment #1)
I don't have much to add. I added support for stabs because that's what is useful to me and CodeWeavers. There's no argument against DWARF support implicit in that decision.
I know next to nothing about DWARF. From what I can tell, Charles, your summary seems about correct, and suggests that adding support for DWARF will be much more complicated than stabs was, or than DWARF is on Linux.
Apparently, GDB will find the .dSYM bundle via a search heuristic. It will also find DWARF info in the original .o files, provided that they are in their original location. We may want DbgHelp to do the same. Unfortunately, GDB makes use of an Apple-private framework to do the searching.
A bit of experimentation shows that the paths to the .o files are referenced via stabs-style entries in the executable (assuming they aren't stripped). So, it may be possible to use the current stabs support to find the .o files, then import the DWARF info from them. Unfortunately, that requires some address mapping.
I found this article from an Apple engineer who helped design and implement their DWARF support: http://wiki.dwarfstd.org/index.php?title=Apple%27s_%22Lazy%22_DWARF_Scheme
http://bugs.winehq.org/show_bug.cgi?id=22384
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|Mac OS X 10.6 |Mac OS X
http://bugs.winehq.org/show_bug.cgi?id=22384
--- Comment #3 from Austin English austinenglish@gmail.com 2013-11-13 16:49:09 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=22384
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #4 from Austin English austinenglish@gmail.com --- Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=22384
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|ABANDONED |---
--- Comment #5 from Ken Thomases ken@codeweavers.com --- Reopened. Yes, this is still an issue in current Wine.
https://bugs.winehq.org/show_bug.cgi?id=22384
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #6 from Ken Thomases ken@codeweavers.com --- I have submitted patches to implement support for finding and loading external DWARF debug files. You have to arrange to create them yourself.
https://source.winehq.org/patches/data/112408 https://source.winehq.org/patches/data/112409 https://source.winehq.org/patches/data/112410 https://source.winehq.org/patches/data/112411
https://bugs.winehq.org/show_bug.cgi?id=22384
Ken Thomases ken@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |5c39776327c09cca39581c1ebab | |3d3f281685caf Status|REOPENED |RESOLVED Resolution|--- |FIXED
--- Comment #7 from Ken Thomases ken@codeweavers.com --- The changes have been committed. By the way, I neglected to thank Eric for his earlier work on dbghelp which made it fairly easy to add this DWARF support for OS X. Thanks!
https://bugs.winehq.org/show_bug.cgi?id=22384
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.47.
https://bugs.winehq.org/show_bug.cgi?id=22384
nidhi nidhijain.pe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nidhijain.pe@gmail.com
--- Comment #9 from nidhi nidhijain.pe@gmail.com --- Created attachment 77734 --> https://bugs.winehq.org/attachment.cgi?id=77734 .exe file not opening
###BOTTLING### customprefix.sh /Applications/Wine.app/Contents/Frameworks/WBottler.framework/Resources/bottler.sh: line 39: /Applications/Wine.app/Contents/Resources/bin/wine: Bad CPU type in executable ###BOTTLING### Gathering debug Info...
Versions OS...........................: darwin20 Wine.........................: WineBottler..................: 1.8.6 Executing cd /Users/apple/Library/Application Support/Wine Wineticks....................: 20240105-next - sha256sum: a3a3ae397556d2d9483bccc36b45ef170ac0ac5c61d0bb6a1d1b01d2078f128c
Environment PWD..........................: '/Applications/Wine.app/Contents/Resources/bin' PATH.........................: /Applications/Wine.app/Contents/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin USER.........................: apple HOME.........................: /Users/apple COMPUTERNAME.................: Appleâs MacBook Air BUNDLERESOURCEPATH...........: /Applications/Wine.app/Contents/Frameworks/WBottler.framework/Resources WINEPREFIX...................: /Applications/Wine.app/Contents/Resources WINEPATH.....................: /Applications/Wine.app/Contents/Resources/bin LD_LIBRARY_PATH..............: /Applications/Wine.app/Contents/Resources/lib:/opt/X11/lib:/usr/X11/lib DYLD_FALLBACK_LIBRARY_PATH...: /Applications/Wine.app/Contents/Resources/lib:/usr/lib:/opt/X11/lib:/usr/X11/lib SILENT.......................: http_proxy...................: https_proxy..................: ftp_proxy....................: socks5_proxy.................:
Bottle TEMPLATE.....................: BOTTLE.......................: /Users/apple/Wine Files INSTALLER_URL................: INSTALLER_IS_ZIPPED..........: 0 INSTALLER_NAME...............: INSTALLER_ARGUMENTS..........: REMOVE_MONO..................: REMOVE_GECKO.................: REMOVE_USERS.................: REMOVE_INSTALLERS............: WINETRICKS_ITEMS.............: DLL_OVERRIDES................: EXECUTABLE_PATH..............: notneeded EXECUTABLE_ARGUMENTS.........: EXECUTABLE_VERSION...........: 1.0.0 BUNDLE_COPYRIGHT.............: BUNDLE_IDENTIFIER............: org.kronenberg.winebottler BUNDLE_CATEGORYTYPE..........: public.app-category.utilities SILENT.......................:
Hardware:
Hardware Overview:
Model Name: MacBook Air Model Identifier: MacBookAir6,1 Processor Name: Dual-Core Intel Core i5 Processor Speed: 1.3 GHz Number of Processors: 1 Total Number of Cores: 2 L2 Cache (per Core): 256 KB L3 Cache: 3 MB Hyper-Threading Technology: Enabled Memory: 4 GB System Firmware Version: 478.0.0.0.0 SMC Version (system): 2.12f143 Serial Number (system): C02MM0HSF5N7 Hardware UUID: 0A7A6384-C3BE-55F7-AD77-3BC72391EDA5 Provisioning UDID: 0A7A6384-C3BE-55F7-AD77-3BC72391EDA5
###BOTTLING### Enabling CoreAudio, Colors, Antialiasing and flat menus... /Applications/Wine.app/Contents/Frameworks/WBottler.framework/Resources/bottler.sh: line 134: /Applications/Wine.app/Contents/Resources/bin/wine: Bad CPU type in executable ### LOG ### Command '/Applications/Wine.app/Contents/Resources/bin/wine regedit /tmp/reg.reg' returned status 126.
###ERROR### Command '/Applications/Wine.app/Contents/Resources/bin/wine regedit /tmp/reg.reg' returned status 126. Task returned with status 1. ned with status 1.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla