tag:blogger.com,1999:blog-84995032320982028202024-03-05T04:49:22.950-08:00Linux debugger bitsAnonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.comBlogger19125tag:blogger.com,1999:blog-8499503232098202820.post-44904740295305252832014-12-02T16:30:00.000-08:002014-12-02T16:30:20.295-08:00Building gdb 7.8.1 on Mint 17; You can check the configuration of your current gdb with:<br />
gdb --configuration<br />
This GDB was configured as follows:<br />
configure --host=x86_64-linux-gnu --target=x86_64-linux-gnu<br />
--with-auto-load-dir=$debugdir:$datadir/auto-load<br />
--with-auto-load-safe-path=$debugdir:$datadir/auto-load<br />
--with-expat<br />
--with-gdb-datadir=/usr/share/gdb (relocatable)<br />
--with-jit-reader-dir=/usr/lib/gdb (relocatable)<br />
--without-libunwind-ia64<br />
--with-lzma<br />
--with-python=/usr (relocatable)<br />
--with-separate-debug-dir=/usr/lib/debug (relocatable)<br />
--with-system-gdbinit=/etc/gdb/gdbinit<br />
--with-zlib<br />
--without-babeltrace<br />
<div>
<br /></div>
<div>
; Snag the gdb 7.8.1 tarfile</div>
<div>
wget http://ftp.gnu.org/gnu/gdb/gdb-7.8.1.tar.xz</div>
<br />
; untar, cd into gdb-7.8.1<br />
<br />
; If you want python 2.7, install libpython2.7-dev instead.<br />
sudo apt-get install libpython3.4-dev liblzma-dev<br />
<br />
; Run configure<br />
./configure --host=x86_64-linux-gnu --with-lzma --target=x86_64-linux-gnu --with-expat --with-python=/usr/bin/python3.4 --with-separate-debug-dir=/usr/lib/debug --with-gdb-datadir=/usr/share/gdb --with-jit-reader-dir=/usr/lib/gdb --with-system-gdbinit=/etc/gdb/gdbinit --without-guile<br />
<br />
; And build it.<br />
make -j 18Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-45804184903293315822014-09-29T13:01:00.000-07:002014-09-29T13:03:35.151-07:00glibtop: This machine has 56 CPUs, 32 are being monitoredFully building TF2 dedicated server was taking around 13 minutes, 10 seconds on this:<br />
<br />
Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz<br />
mikesart@mikesart-petra:~$ grep -c model.name /proc/cpuinfo<br />
12<br />
<br />
I tend to muck with the lower level libraries which meant I was spending quite a bit of my day waiting for these builds to finish.<br />
<br />
TF2 dedicated server has:<br />
- 1347 cpp files<br />
- 13 DSOs (with 13 .dbg files)<br />
- 12 static libraries<br />
<br />
I looked at several things: ccache, precompiled headers, distcc, unity builds. We are using ccache fulltime, but when I switch between debug / release or add a new define here and there, it wasn't helping as much as I'd like. Distcc meant I'd have to manage several other machines, and the unity builds seemed like a whole bunch of work also. The precompiled headers gave a decent win (down to around 7 minutes), but (from what I could tell), the .gch file really wants to be where the main header file lives. We do debug/release/client/dedicated server builds all out of the same tree and this just won't work.<br />
<br />
So I got one of these:<br />
<br />
(2) Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz<br />
mikesart@mikesart-mint:~/valvesrc/ValveGames/staging/game$ grep -c model.name /proc/cpuinfo<br />
56<br />
<br />
The build time is now 3 minutes, 30 seconds.<br />
<br />
I tried creating a ramdisk and putting the entire source tree and tmp directory there, and the build time was still 3m30s (compared to building from a Samsung SSD 850 PRO 512GB). I think a decent chunk of time right now is going towards linking - so I'm going to investigate the gold linker and see if I can get a bit more time back from that.<br />
<br />
We are currently using gcc 4.6.1 crosstools w/ glibc-2.11.1. I'm going to investigate newer versions of gcc and clang when I get more time to play with this stuff. Have some bugs and features before I get to play more - hopefully turnaround will go a bit faster now though...<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVeqCGzzFc2Tu8toiQhtvB7Z9L2tkk2mUtYMmZaXy6vQ4szDONRixt8WHWQGPvbJm9xrlT4xXwHP8sHwE5uYchZeg1klQ3VDMinKnUtNg9iaaEumpte9JOs0U58oeUkNzAyPRzy2iO9-I/s1600/htop.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVeqCGzzFc2Tu8toiQhtvB7Z9L2tkk2mUtYMmZaXy6vQ4szDONRixt8WHWQGPvbJm9xrlT4xXwHP8sHwE5uYchZeg1klQ3VDMinKnUtNg9iaaEumpte9JOs0U58oeUkNzAyPRzy2iO9-I/s1600/htop.jpg" height="306" width="640" /></a></div>
<br />Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-46729756434172169442014-06-08T16:52:00.000-07:002014-06-08T16:52:20.380-07:00Gdb script to spew malloc backtracesWe've got an app where "perf top" is showing malloc being called a lot. Now we need to figure out who is calling it.<br />
<br />
Couple of ideas are obviously to use tcmalloc or something like this:<br />
<br />
<a href="https://fedex1.valvesoftware.com/owa/redir.aspx?C=A9zy3nEpGUq9iOPrnpSJ7D9S9mUCV9EICpJYb-OBFkfwWnB9uNHRYZ68hUryxd70oiPz5ay6E_o.&URL=http%3a%2f%2fman7.org%2flinux%2fman-pages%2fman3%2fmalloc_hook.3.html" target="_blank">http://man7.org/linux/man-pages/man3/malloc_hook.3.html</a><br />
<br />
However these are live game instances running on a server somewhere in Germany (for example), and it's not easy to restart and preload DSOs. People playing on that server tend to frown upon this behavior also. :)<br />
<br />
Came up with the idea to try using gdb to connect, set a breakpoint and log the next X hundred of the callstacks to a logfile. Script is down below. I've tried it on glxspheres and it seems like it'll work. I'm sure others have done this - if so and you have any comments / suggestions, please let me know.<br />
<br />
<pre br="">#
# Use via something like this:
# gdb -x ~/bin/spewmallocscript.gdb --pid=$(pidof glxspheres64)
#
# Make sure we never get asked y/n
set pagination off
# Overwrite logfile
set logging overwrite on
set logging file /tmp/gdb_malloc_calls.txt
set logging on
printf "\n\nSetting malloc breakpoint\n"
break malloc
set $i=0
set $count=100
printf "Logging %d callstacks...\n\n", $count
# add command for malloc breakpoint
commands
silent
bt 16
if $i < $count
printf "\ncall #%d:\n", $i
set $i=$i+1
else
set logging redirect off
quit
end
c
end
# send output to log file only
set logging redirect on
c
<div>
</div>
</pre>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-30140440672573707012014-06-03T10:28:00.002-07:002014-06-03T11:30:59.318-07:00Man (and less) colors...I had the following set in my environment.<br />
<br />
export LESS='-QRS'<br />
export LESS_TERMCAP_mb=$'\E[01;31m'<br />
export LESS_TERMCAP_md=$'\E[01;38;5;74m'<br />
export LESS_TERMCAP_me=$'\E[0m'<br />
export LESS_TERMCAP_so="$(printf 'rev\nbold\nsetaf 3\n' | tput -S)"<br />
export LESS_TERMCAP_se="$(tput sgr0)"<br />
export LESS_TERMCAP_us=$'\E[04;38;5;146m'<br />
export LESS_TERMCAP_ue=$'\E[0m'<br />
<br />
Made for nice colored man pages. Unfortunately, when I used the "env" command, environment variables following the LESS_TERMCAP_* variables got mucked up: underlined, etc.<br />
<br />
So I unset them and now use this alias:<br />
<br />
alias man="LESS_TERMCAP_mb=$'\E[01;31m' LESS_TERMCAP_md=$'\E[01;38;5;74m' LESS_TERMCAP_me=$'\E[0m' LESS_TERMCAP_se=$'\E[0m' LESS_TERMCAP_so=$'\E[48;5;3<br />
m\E[38;5;0m' LESS_TERMCAP_ue=$'\E[0m' LESS_TERMCAP_us=$'\E[04;38;5;146m' man"<br />
<br />
alias less="LESS_TERMCAP_mb=$'\E[01;31m' LESS_TERMCAP_md=$'\E[01;38;5;74m' LESS_TERMCAP_me=$'\E[0m' LESS_TERMCAP_se=$'\E[0m' LESS_TERMCAP_so=$'\E[48;5;3<br />
m\E[38;5;0m' LESS_TERMCAP_ue=$'\E[0m' LESS_TERMCAP_us=$'\E[04;38;5;146m' less"<br />
<br />
Not sure it's the best solution, but it seemed better than the lesskey stuff. Also found the prompt option and added that:<br />
<br />
export LESS='-QRS --prompt="%f (%pb\%, %lmth line, %L lines)$ '<br />
<br />
The final fairly useful thing from poking in the code is the LESS_TERMCAP_DEBUG environment variable. It highlights the section names which is pretty darn useful for figuring the colors out. Example:<br />
<pre>mikesart@mikesart-petra:~/dev$ LESS_TERMCAP_DEBUG=1 man strstr
<ti><ks><cr>STRSTR(3) Linux Programmer's Manual</pre>
<pre><md>NAME<me>
strstr, strcasestr - locate a substring
<md>SYNOPSIS<me>
<md>#include<me> <md><string.h><me>
... strstr(3) line 1/43 (END) (press h for help or q to quit)<se><ce>
<div>
</div>
</pre>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-10401024275809616232014-04-30T10:30:00.004-07:002014-04-30T10:30:55.963-07:0032-bit Valgrind Notes1. When running ./configure to build valgrind, look for this line:<br />
<br />
checking for 32 bit build support... yes<br />
<br />
You can also use --enable-only64bit or --enable-only32bit if you only care about a specific platform.<br />
<br />
2. Adding "-d" to valgrind will spew out a bunch of debug information, including which tool it's launching. Something like this:<br />
<br />
--4603:1:launcher no client specified, defaulting platform to 'amd64-linux'<br />
--4603:1:launcher launching /usr/local/lib/valgrind/memcheck-amd64-linux<br />
<br />
"valgrind --verbose" can also be useful, of course.<br />
<br />
3. Archive of valgrind users mailing list is here:<br />
<br />
http://valgrind.10908.n7.nabble.com/Valgrind-Users-f33662i35.html<br />
<br />
4. If you see this error when valgrind'ing a 32-bit application:<br />
<br />
valgrind: Fatal error at startup: a function redirection<br />
valgrind: which is mandatory for this platform-tool combination<br />
valgrind: cannot be set up. Details of the redirection are:<br />
valgrind: <br />
valgrind: A must-be-redirected function<br />
valgrind: whose name matches the pattern: strlen<br />
valgrind: in an object with soname matching: ld-linux.so.2<br />
valgrind: was not found whilst processing<br />
valgrind: symbols from the object with soname: ld-linux.so.2<br />
valgrind: <br />
valgrind: Possible fixes: (1, short term): install glibc's debuginfo<br />
valgrind: package on this machine. (2, longer term): ask the packagers<br />
valgrind: for your Linux distribution to please in future ship a non-<br />
valgrind: stripped ld.so (or whatever the dynamic linker .so is called)<br />
valgrind: that exports the above-named function using the standard<br />
valgrind: calling conventions for this platform. The package you need<br />
valgrind: to install for fix (1) is called<br />
valgrind: <br />
valgrind: On Debian, Ubuntu: libc6-dbg<br />
valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo<br />
valgrind: <br />
valgrind: Cannot continue -- exiting now. Sorry.<br />
<div>
<br /></div>
<div>
You most likely need the 32-bit libc-dbg package. On Debian based systems this should fix it:</div>
<div>
<br /></div>
<div>
sudo apt-get install libc6-dbg:i386</div>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-87047457295217443092014-04-29T15:14:00.000-07:002014-04-29T15:14:40.873-07:00Valgrind NotesCouple notes.<br />
<br />
1. Command line for running valgrind with vogl capturing glxspheres64 from the vogl_build/bin directory:<br />
<br />
valgrind --tool=memcheck --leak-check=full --error-limit=no
--trace-children=yes --time-stamp=yes --log-file=/tmp/blah.log --
../../bin/steamlauncher.sh --amd64 --gameid ./glxspheres64<br />
<br />
2. Found some good stuff. Also a few things like this... :)<br />
<br /> // Get some entropy from the heap.<br /> p[i] = vogl_malloc(65536 * (i + 1));<br /> gen.update_obj_bits(p[i]);<br /> if (p[i])<br /> {<br /> for (uint j = 0; j < 16; j++)<br /> gen.update_obj_bits(reinterpret_cast<const uint64_t *>(p)[j]);<br /> }<br /><br />2. Adding --track-origins=yes to the command line slows Valgrind down quite a bit but can really help. It added the line in bold for this stack trace (which wasn't making sense until we got this hint):<br /><br />
<span style="font-size: x-small;">Uninitialised byte(s) found during client check request </span><br />
<span style="font-size: x-small;"> at 0x5422873: vogl_trace_stream_start_of_file_packet::compute_crc() const (vogl_trace_stream_types.h:185)</span><br />
<span style="font-size: x-small;"> by 0x54227B1: vogl_trace_stream_start_of_file_packet::check_crc(unsigned int) const (vogl_trace_stream_types.h:231)</span><br />
<span style="font-size: x-small;"> by 0x5421EE8: vogl_trace_stream_start_of_file_packet::full_validation(unsigned int) const (vogl_trace_stream_types.h:242)</span><br />
<span style="font-size: x-small;"> by 0x5420CB7: vogl_trace_file_writer::open(char const*, vogl_archive_blob_manager*, bool, bool, unsigned int) (vogl_trace_file_writer.cpp:82)</span><br />
<span style="font-size: x-small;"> by 0x517BAC0: vogl_global_init() (vogl_intercept.cpp:799) </span><br />
<span style="font-size: x-small;"> by 0x92E236F: pthread_once (pthread_once.S:103)</span><br />
<span style="font-size: x-small;"> by 0x517A970: vogl_entrypoint_prolog(gl_entrypoint_id_t) (vogl_intercept.cpp:865) </span><br />
<span style="font-size: x-small;"> by 0x50B3382: vogl_glXChooseVisual(_XDisplay const*, int, int const*) (gl_glx_func_defs.inc:91640)</span><br />
<span style="font-size: x-small;"> by 0x50B3302: glXChooseVisual (gl_glx_func_defs.inc:91635)</span><br />
<span style="font-size: x-small;"> by 0x403C84: main (glxspheres.c:716)</span><br />
<span style="font-size: x-small;"> Address 0x59632bd is 149 bytes inside data symbol "_ZZL21get_vogl_trace_writervE19s_vogl_trace_writer"</span><br />
<span style="font-size: x-small;"><b> Uninitialised value was created by a stack allocation</b></span><br />
<span style="font-size: x-small;"><b> at 0x5536214: vogl::init_uuid() (vogl_uuid.cpp:53)</b></span><br />
<div>
<br /></div>
3. And finally, if that doesn't do it, you can use code like this to help even more:<br /><br /> #include "memcheck.h"<br /> ... <br /> uintptr_t addr = VALGRIND_CHECK_MEM_IS_DEFINED(ptr, len);<br /> if (addr)<br /> {<br /> printf("VALGRIND_CHECK_MEM failed: %p %u\n", ptr, len);<br /> printf(" addr = %p\n", (void *)addr);<br /> }<br /><br />
Documentation for these markups (and much, much more) here:<br />
<br />
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs<br />
<br />Just grab valgrind.h and memcheck.h. We've checked them into the extlib/valgrind directory in vogl.<br />Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-34692888818825872032014-04-24T13:28:00.000-07:002014-04-24T13:28:32.566-07:00Bash SymbolsDebugging an issue where our preloaded vogl shared object is crashing bash. These are the steps I did to get the bash symbols on Linux Mint 16:<br />
<br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">echo "deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse</span><br />
<span style="background-color: #eeeeee; font-family: 'Courier New', Courier, monospace;">deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse</span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">deb http://ddebs.ubuntu.com $(lsb_release -cs)-security main restricted universe multiverse</span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">deb http://ddebs.ubuntu.com $(lsb_release -cs)-proposed main restricted universe multiverse" | \</span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">sudo tee -a /etc/apt/sources.list.d/ddebs.list</span><br />
<br />
<span style="font-family: inherit;"># NOTE: Since I'm on Linux Mint (Petra) I then had to edit ddebs.list and change petra to saucy.</span><br />
<br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="background-color: #eeeeee; font-family: 'Courier New', Courier, monospace;">wget -q http://ddebs.ubuntu.com/dbgsym-release-key.asc</span><br />
<span style="background-color: #eeeeee;"><span style="font-family: Courier New, Courier, monospace;"></span></span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">sudo apt-key add dbgsym-release-key.asc</span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;"><br /></span>
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">sudo apt-get update</span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;"><br /></span>
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">apt-cache policy bash</span><br />
<br />
# Returns something like this:<br />
<br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">> bash:</span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">> Installed: <b>4.2-5ubuntu3</b></span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">> Candidate: 4.2-5ubuntu3</span><br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">> ...</span><br />
<span style="background-color: #eeeeee;"><br /></span>
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">sudo apt-get install bash-dbgsym=<b>4.2-5ubuntu3</b></span><br />
<br />
# Grab the source:<br />
<br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">apt-get source bash</span><br />
<span style="background-color: #eeeeee;"><br /></span>
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">cd bash-4.2</span><br />
<br />
<span style="font-family: inherit;"># Untar the source (I use atool, feel free to use tar xf or whatever):</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">atool -x bash-4.2.tar.xz</span><br />
<br />
# Now in gdb (or your .gdbinit) you can point to the bash source. For me:<br />
<br />
<span style="background-color: #eeeeee; font-family: Courier New, Courier, monospace;">directory /home/mikesart/src/bash-4.2/bash-4.2</span><br />
<br />
# Here are a couple of good of good links for all this.<br />
<br />
https://wiki.ubuntu.com/DebuggingProgramCrash<br />
<br />
http://yaapb.wordpress.com/2012/12/28/debugging-your-running-kernel-in-ubuntu/<br />
<br />
http://randomascii.wordpress.com/2013/01/08/symbols-on-linux-part-one-g-library-symbols/Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com2tag:blogger.com,1999:blog-8499503232098202820.post-59521296093322746472014-01-09T14:24:00.000-08:002014-01-09T14:24:15.544-08:00QtCreator and Ninja warning/error parsingWe have a custom build binary that launches ninja and we couldn't get QtCreator to parse the warnings from that output. Errors/warnings show up, they just weren't being parsed. I finally got QtCreator building with symbols and tracked it down to this in makestep.cpp:<br />
<br />
267 if (m_useNinja)<br />
268 AbstractProcessStep::stdError(line);<br />
269 else<br />
270 AbstractProcessStep::stdOutput(line);<br />
<br />
Ninja is processing stderr and regular makefiles are processing stdout. So I added this to our custom shell script and it's working now:<br />
<br />
Command: .../bin/mkvogl.sh<br />
Arguments: --amd64 --debug 3>&1 1>&2 2>&3<br />
<br />
I guess if you ever find QtCreator isn't parsing your output, try swapping stderr and stdout. :)<br />
<br />
If anyone wants to get QtCreator building release with symbols on something vaguely resembling 64-bit Linux Mint 16, this is what I wound up doing:<br />
<br />
apt-get install: libgl1-mesa-dev libxml2-dev libglib2.0-dev libxslt1-dev libglib2.0-dev libgstreamer-plugins-base0.10-dev libgstreamer0.10-dev<br />
<blockquote class="tr_bq">
diff --git a/qtcreator.pri b/qtcreator.pri<br />index 1750705..9be9c03 100644<br />--- a/qtcreator.pri<br />+++ b/qtcreator.pri<br />@@ -180,6 +180,9 @@ unix {<br /><br /> RCC_DIR = $${OUT_PWD}/.rcc<br /> UI_DIR = $${OUT_PWD}/.uic<br />+<br />+ QMAKE_CXXFLAGS_RELEASE += -g<br />+ QMAKE_CFLAGS_RELEASE += -g<br /> }<br /><br /> win32-msvc* {</blockquote>
cd ~/dev/qt-creator/src<br />
qmake -r<br />
make<br />
<br />
If there is a better way of achieving this, please let me know - I don't know much about qmake and couldn't find anything...Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com4tag:blogger.com,1999:blog-8499503232098202820.post-24685706431349341882014-01-08T11:23:00.002-08:002014-01-08T11:23:18.880-08:00QtCreator projects<div style="color: #222222; font-family: arial; font-size: small;">
I've switched to using QtCreator 3.0 as my main editor. I'm really liking it (and FakeVim!), but one big issue we've run into is projects. What files are loaded, what defines are set, files not listed in our makefiles (.sh), listing include files in our makefiles just so they're in the project, etc. It also likes to blast .user files where you open your makefile and now we're dealing with getting mercurial or git to ignore those, etc.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
I wrote the below which just finds everything under our vogl project directory with specified extensions. It also takes some patterns to remove files after the fact (possibly someone can tell me a more optimal way of doing this?).</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
Next I'm going to figure out how to get QtCreator to parse ninja build output. (Grumble, grumble. :)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
In any case, throwing it up here in case someone might find it useful...</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
#</div>
<div style="color: #222222; font-family: arial; font-size: small;">
# VoglProj QtCreator cmake file.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
#</div>
<div style="color: #222222; font-family: arial; font-size: small;">
# Do the following in the directory above your vogl enlistment:</div>
<div style="color: #222222; font-family: arial; font-size: small;">
#</div>
<div style="color: #222222; font-family: arial; font-size: small;">
# ln -s vogl/bin/qtcreator/CMakeLists.txt</div>
<div style="color: #222222; font-family: arial; font-size: small;">
#</div>
<div style="color: #222222; font-family: arial; font-size: small;">
# Then open it up with QtCreator and you should be off and running.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
#</div>
<div style="color: #222222; font-family: arial; font-size: small;">
project(VoglProj)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
cmake_minimum_required(VERSION 2.8)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
# List of file extensions that we search for.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
set(EXTLIST *.i *.sh *.inl *.inc *.txt *.vs *.vp *.frag *.vert *.py *.m *.c* *.h* *.S)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
# Vogl directory.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
set(VOGL_DIR "${CMAKE_CURRENT_SOURCE_DIR}/vogl")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
if(NOT EXISTS "${VOGL_DIR}/")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
message("\nERROR: ${VOGL_DIR} does not exist. Please put this script one level up from your vogl enlistement.\n")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
message(FATAL_ERROR "Exiting...")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
endif()</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
# Create list of vogl directorie plus extensions.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
set(GLOBSPEC)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
foreach(ext ${EXTLIST})</div>
<div style="color: #222222; font-family: arial; font-size: small;">
list(APPEND GLOBSPEC ${VOGL_DIR}/${ext})</div>
<div style="color: #222222; font-family: arial; font-size: small;">
endforeach()</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
# Search for all the files.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
file(GLOB_RECURSE vogl_srcs</div>
<div style="color: #222222; font-family: arial; font-size: small;">
RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}</div>
<div style="color: #222222; font-family: arial; font-size: small;">
${GLOBSPEC}</div>
<div style="color: #222222; font-family: arial; font-size: small;">
)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
# Macro to remove files based on regex pattern.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
macro(RemoveSrcFiles pat)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
set(result)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
foreach(file ${vogl_srcs})</div>
<div style="color: #222222; font-family: arial; font-size: small;">
if(file MATCHES ${pat})</div>
<div style="color: #222222; font-family: arial; font-size: small;">
else()</div>
<div style="color: #222222; font-family: arial; font-size: small;">
list(APPEND result ${file})</div>
<div style="color: #222222; font-family: arial; font-size: small;">
endif()</div>
<div style="color: #222222; font-family: arial; font-size: small;">
endforeach()</div>
<div style="color: #222222; font-family: arial; font-size: small;">
set(vogl_srcs ${result})</div>
<div style="color: #222222; font-family: arial; font-size: small;">
endmacro()</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
# Remove all files under .git and .hg directories.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
RemoveSrcFiles("/[.]git/")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
RemoveSrcFiles("/[.]hg/")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
# Spew out all files we've found.</div>
<div style="color: #222222; font-family: arial; font-size: small;">
set(count 0)</div>
<div style="color: #222222; font-family: arial; font-size: small;">
foreach(file ${vogl_srcs})</div>
<div style="color: #222222; font-family: arial; font-size: small;">
message("${file}")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
math(EXPR count "${count} + 1")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
endforeach()</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
message("${count} files added.\n")</div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
<div style="color: #222222; font-family: arial; font-size: small;">
add_executable(VoglProj ${vogl_srcs})</div>
<div style="color: #222222; font-family: arial; font-size: small;">
set_target_properties(VoglProj PROPERTIES LINKER_LANGUAGE C)</div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com1tag:blogger.com,1999:blog-8499503232098202820.post-86049444279065756582013-10-16T10:12:00.002-07:002013-10-16T10:12:36.722-07:00GCC 4.8 on Ubuntu 12.04 x64Ran into a bug in libstdc++ 4.7 building LLDB with Clang 3.3. So these are the notes on getting GCC 4.8 installed.<br />
<br />
Here is a link talking about the libstdc++ bug:<br />
<a href="http://stackoverflow.com/questions/15747223/why-does-this-basic-thread-program-fail-with-clang-but-pass-in-g">http://stackoverflow.com/questions/15747223/why-does-this-basic-thread-program-fail-with-clang-but-pass-in-g</a><br />
<br />
Good askubuntu link:<br />
http://askubuntu.com/questions/193513/problem-adding-a-ppa-to-install-gcc-4-7<br />
<br />
Ubuntu Toolchain PPA:<br />
<a href="https://launchpad.net/~ubuntu-toolchain-r/+archive/test">https://launchpad.net/~ubuntu-toolchain-r/+archive/test</a><br />
<br />
<span style="font-family: inherit;">Steps:</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="background-color: #cccccc; font-family: inherit;">sudo add-apt-repository ppa:ubuntu-toolchain-r/test</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">If that doesn't work, you can create the file manually:</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="background-color: #cccccc; font-family: inherit;">mikesart@mikesart64:~/data/src/blah/build64$ cat /etc/apt/sources.list.d/toolchain.list</span><br />
<span style="background-color: #cccccc; font-family: inherit;"># https://launchpad.net/~ubuntu-toolchain-r/+archive/test</span><br />
<span style="background-color: #cccccc; font-family: inherit;">deb http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise main </span><br />
<span style="background-color: #cccccc;"><span style="font-family: inherit;">deb-src http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu precise mai</span><span style="font-family: inherit;">n</span></span><br />
<span style="font-family: inherit;"><br /></span>
<span style="background-color: #cccccc; font-family: inherit;">sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 1E9377A2BA9EF27F</span><br />
<span style="background-color: #cccccc; font-family: inherit;">sudo apt-get update</span><br />
<span style="background-color: #cccccc; font-family: inherit;">sudo apt-get install gcc-4.8 g++-4.8</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">I then added gcc 4.8 to my alternatives list.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="background-color: #cccccc; font-family: inherit;">sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 50</span><br />
<span style="background-color: #cccccc; font-family: inherit;">sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 50</span><br />
<span style="background-color: #cccccc; font-family: inherit;">sudo update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-4.8 50</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">Here are some clang / gcc commands to view various options, include paths, etc.</span><br />
<br />
<b style="background-color: white;"># Show default options and commands, plus include paths</b><br />
<span style="background-color: #cccccc;">mikesart@mikesart64:~/data/src/llvm.svn/build$ clang -v -fsyntax-only -x c++ /dev/null 2>&1</span><br />
<span style="background-color: #cccccc;">clang version 3.3 (tags/RELEASE_33/final)</span><br />
<span style="background-color: #cccccc;">Target: x86_64-unknown-linux-gnu</span><br />
<span style="background-color: #cccccc;">Thread model: posix</span><br />
<span style="background-color: #cccccc;"> "/home/mikesart/data/src/clang3.3/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -disable-free -disable-llvm-verifier -main-file-name null -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.20.1 -v -resource-dir /home/mikesart/data/src/clang3.3/bin/../lib/clang/3.3 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/x86_64-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8 -internal-isystem /usr/local/include -internal-isystem /home/mikesart/data/src/clang3.3/bin/../lib/clang/3.3/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir /home/mikesart/data/src/llvm.svn/build -ferror-limit 19 -fmessage-length 181 -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -x c++ /dev/null</span><br />
<span style="background-color: #cccccc;">clang -cc1 version 3.3 based upon LLVM 3.3 default target x86_64-unknown-linux-gnu</span><br />
<span style="background-color: #cccccc;">ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/x86_64-linux-gnu"</span><br />
<span style="background-color: #cccccc;">ignoring nonexistent directory "/include"</span><br />
<span style="background-color: #cccccc;">#include "..." search starts here:</span><br />
<span style="background-color: #cccccc;">#include <...> search starts here:</span><br />
<span style="background-color: #cccccc;"> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8</span><br />
<span style="background-color: #cccccc;"> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward</span><br />
<span style="background-color: #cccccc;"> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8</span><br />
<span style="background-color: #cccccc;"> /usr/local/include</span><br />
<span style="background-color: #cccccc;"> /home/mikesart/data/src/clang3.3/bin/../lib/clang/3.3/include</span><br />
<span style="background-color: #cccccc;"> /usr/include/x86_64-linux-gnu</span><br />
<span style="background-color: #cccccc;"> /usr/include</span><br />
<span style="background-color: #cccccc;">End of search list.</span><br />
<br />
<b style="background-color: white;"># Print the paths used for finding libraries and programs</b><br />
<span style="background-color: #cccccc;">mikesart@mikesart64:~/data/src/llvm.svn/build$ clang -print-search-dirs | tr : '\n'</span><br />
<span style="background-color: #cccccc;">programs</span><br />
<span style="background-color: #cccccc;"> =/home/mikesart/bin</span><br />
<span style="background-color: #cccccc;">/home/mikesart/data/src/clang3.3/bin</span><br />
<span style="background-color: #cccccc;">/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/bin</span><br />
<span style="background-color: #cccccc;">libraries</span><br />
<span style="background-color: #cccccc;"> =/home/mikesart/data/src/clang3.3/bin/../lib/clang/3.3</span><br />
<span style="background-color: #cccccc;">/usr/lib/gcc/x86_64-linux-gnu/4.8</span><br />
<span style="background-color: #cccccc;">/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu</span><br />
<span style="background-color: #cccccc;">/lib/x86_64-linux-gnu</span><br />
<span style="background-color: #cccccc;">/lib/../lib64</span><br />
<span style="background-color: #cccccc;">/usr/lib/x86_64-linux-gnu</span><br />
<span style="background-color: #cccccc;">/usr/lib/gcc/x86_64-linux-gnu/4.8/../../..</span><br />
<span style="background-color: #cccccc;">/lib</span><br />
<span style="background-color: #cccccc;">/usr/lib</span><br />
<br />
<b style="background-color: white;"># list all preprocessor definitions</b><br />
<span style="background-color: #cccccc;">clang -dM -E - < /dev/null</span><br />
<span style="background-color: #cccccc;">#define _LP64 1</span><br />
<span style="background-color: #cccccc;">#define __ATOMIC_ACQUIRE 2</span><br />
<span style="background-color: #cccccc;">#define __ATOMIC_ACQ_REL 4</span><br />
<span style="background-color: #cccccc;">#define __ATOMIC_CONSUME 1</span><br />
<span style="background-color: #cccccc;">#define __ATOMIC_RELAXED 0</span><br />
<span style="background-color: #cccccc;">#define __ATOMIC_RELEASE 3</span><br />
<span style="background-color: #cccccc;">#define __ATOMIC_SEQ_CST 5</span><br />
<br />
<span style="background-color: #cccccc;">#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__</span><br />
<span style="background-color: #cccccc;">...</span><br />
<div>
<br /></div>
Link for gcc options which control kind of output:<br />
http://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Overall-Options.html<br />
<br />
This one really useful: "If the -Q option appears on the command line before the --help= option, then the descriptive text displayed by --help= is changed. Instead of describing the displayed options, an indication is given as to whether the option is enabled, disabled or set to a specific value (assuming that the compiler knows this at the point where the --help= option is used)."<br />
<br />
<b style="background-color: white;"># See what gcc enables with native flag (sse, avx, etc)</b><br />
<span style="background-color: #cccccc;"># (Clang 3.3 doesn't appear to support the --help=XX stuff)</span><br />
<span style="background-color: #cccccc;">gcc -march=native -Q --help=target -v</span><br />
<div>
<br /></div>
<div>
--help=XX supports the following:</div>
<div>
optimizers: display all optimization options supported by the compiler.</div>
<div>
warnings: display all options controlling warning messages produced by the compiler.</div>
<div>
target: display target-specific options.</div>
<div>
params: display values recognized by the --param option.</div>
<div>
common: display options that are common to all languages.</div>
<div>
language: display options supported for <var>language<span style="font-style: normal;">, where language = c++, etc.</span></var></div>
<div>
<br /></div>
<div>
You can add undocumented to list all undocumented target-specific switches as well. Ie:</div>
<div>
<br /></div>
<div>
<span style="background-color: #cccccc;">/usr/bin/gcc-4.8 -march=native -Q --help=target,undocumented -v</span></div>
<div>
<span style="background-color: #cccccc;">/usr/bin/gcc-4.8 -march=native -Q --help=c++,undocumented -v</span></div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-25057754263117297942013-10-04T13:53:00.001-07:002013-10-04T13:53:25.506-07:00Simple SSE/AVX/MMX sample source code...For testing a bunch of register stuff in LLDB. Shoved it up here also:<br />
<br />
<a href="https://gist.github.com/mikesart/6832418#file-gistfile1-txt">https://gist.github.com/mikesart/6832418#file-gistfile1-txt</a><br />
<br />
<br />
<pre style="white-space: pre-wrap; word-wrap: break-word;">// Output from my cmake VERBOSE=1 command for building:
// c++ -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES -march=native -g -O0 -std=c++0x -g -o sse.cpp.o -c sse.cpp
// c++ -march=native -g -O0 -std=c++0x -g sse.cpp.o -o sse -rdynamic -ldl -lpthread
// SSE
//
#include <stdio.h>
#include <stdlib.h>
// #include <mmintrin.h> // MMX
// #include <xmmintrin.h> // SSE
// #include <emmintrin.h> // SSE2
// #include <pmmintrin.h> // SSE3
// #include <tmmintrin.h> // SSSE3
// #include <nmmintrin.h> // SSE4.1
// #include <ammintrin.h> // SSE4.2
// #include <wmmintrin.h> // AES/PCMUL
// #include <immintrin.h> // AVX
#include <x86intrin.h> // Pulls in all of the above based on compiler switches (-march)
// AVX, SSE intrinsics, etc.:
// http://chessprogramming.wikispaces.com/AVX
// Intrinsics for Advanced Vector Extensions:
// http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/2011Update/cpp/lin/intref_cls/common/intref_bk_advectorext.htm
// Intrinsics for Advanced Vector Extensions 2:
// http://software.intel.com/sites/products/documentation/hpc/composerxe/en-us/2011Update/cpp/lin/intref_cls/common/intref_bk_advectorext2.htm
#ifndef __AVX__
#error AVX not defined
#endif
int main( int argc, char *argv[] )
{
float a = 16.0f;
float b = 9.0f;
__m128 SSE0 = _mm_setzero_ps();
__m128 SSEa = _mm_set_ps1(a); // _mm_load1_ps(&a);
__m128 SSEb = _mm_set_ps1(b); // _mm_load1_ps(&b);
__m128 SSEv = _mm_add_ps(SSEa, SSEb);
__m256 AVX0 = _mm256_setzero_ps();
__m256 AVXa = _mm256_set1_ps(a);
__m256 AVXb = _mm256_set1_ps(b);
__m256 AVXv = _mm256_add_ps(AVXa, AVXb);
__m64 MMX0 = _mm_setzero_si64();
__m64 MMXa = _mm_setr_pi32(16, 16);
__m64 MMXb = _mm_setr_pi32(9, 9);
__m64 MMXv = _mm_add_pi32(MMXa, MMXb);
float temp[4] __attribute__((aligned(16)));
_mm_store_ps(&temp[0], SSEv);
printf("tempsse is %.2f %.2f %.2f %.2f\n", temp[0], temp[1], temp[2], temp[3]);
float temp2[8] __attribute((aligned(32)));
_mm256_store_ps(&temp2[0], AVXv);
printf("tempavx is %.2f %.2f %.2f %.2f %.2f %.2f %.2f %.2f\n",
temp2[0], temp2[1], temp2[2], temp2[3],
temp2[4], temp2[5], temp2[6], temp2[7]);
printf("%d\n", _mm_cvtsi64_si32(MMXv));
return 0;
}</pre>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-22892729068134486112013-08-03T00:34:00.000-07:002013-08-03T00:34:31.370-07:00More on Linux ThreadsGot Linux thread names working in LLDB. "thread list" will now display the proper thread name and will be updated after calling pthread_setname_np(), etc. Still need thread-events, but that's a bit lower priority right now.<br />
<br />
Couple of interesting notes & questions.<br />
<br />
1. I initially implemented this by reading the "/proc/[pid]/task/[tid]/comm" file. Matt Kopec pointed out this could be read from "/proc/[pid]/comm" as well, even though "/proc/[tid]" isn't visible using ls in the terminal. This directory existing makes sense as threads are just light-weight processes, I just had never thought or read about it anywhere before. (Although to be fair, Pierre-Loup said he mentioned it to me at some point.)<br />
<br />
2. For the curious, "/proc/self" has process granularity. Ie, I read "/proc/self/comm" from a background thread and it was the name of the process.<br />
<br />
3. The "man proc" page for "/proc/[pid]/task" has this warning:<br />
<blockquote class="tr_bq">
In a multithreaded process, the contents of the /proc/[pid]/task directory are not available if the main thread has already terminated (typically by calling pthread_exit(3)).</blockquote>
<br />
If anyone knows a system where this is true, I'd love to hear about it.<br />
<br />
4. Gdb uses this libthread_db library to get notifications about new threads, and it looks like this is quite the doozy to set up and get running. Some great ( and only other than source? :) info on that here:<br />
<br />
<a href="http://timetobleed.com/notes-about-an-odd-esoteric-yet-incredibly-useful-library-libthread_db/">http://timetobleed.com/notes-about-an-odd-esoteric-yet-incredibly-useful-library-libthread_db/</a><br />
<br />
<br />
LLDB doesn't use libthread_db though - it uses signals. Source code can be found in ProcessMonitor.cpp if you search for the "<span class="k">case</span> <span class="p">(</span><span class="n">SIGTRAP</span> <span class="o">|</span> <span class="p">(</span><span class="n">PTRACE_EVENT_CLONE</span> <span class="o"><<</span> <span class="mi">8</span><span class="p">))</span>" statement in <span class="n">ProcessMonitor</span><span class="o">::</span><span class="n">MonitorSIGTRAP</span><span class="p">().</span><br />
<br />
https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/Process/Linux/ProcessMonitor.cpp<br />
<br />
My question would be: why on earth go through all the trouble to use libthread_db if signals will work just as well? <br />
<br />
There is an intriguing note in the libthread_db post where he mentions accessing thread local data:<br />
<blockquote class="tr_bq">
<h3>
Now you can use the library</h3>
At this point, you’ve done enough setup to be able to <code>dlsym</code>
search for and call various functions to iterate over the threads in a
remote process, to be notified asynchronously when threads are created
or destroyed, and to access thread local data if you want to.</blockquote>
Now that could be incredibly useful... but from what I can tell, gdb doesn't use this feature. Getting to tls data in gdb (unless I've missed something) is a bit of a pain in the backside.<br />
<br />
I'm going to put these on the backburner for now and start trying to track down some stack tracing bugs. Which means diving in and trying to understand CIE and FDEs: http://www.airs.com/blog/archives/460<br />
<br />
Good times!Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com4tag:blogger.com,1999:blog-8499503232098202820.post-69309648300209570042013-07-19T11:23:00.000-07:002013-07-19T12:05:48.251-07:00LLDB Project NotesThis has been moved to: <a href="https://bitbucket.org/mikesart/lldb_branch/wiki/LLDB%20Project%20Notes" style="color: #1155cc; font-family: arial; font-size: small;">https://bitbucket.org/mikesart/lldb_branch/wiki/LLDB%20Project%20Notes</a><br />
<br />
#<br />
# Useful links<br />
#<br />
<br />
Subversion Commit Access: http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access<br />
<br />
lldb build page: http://lldb.llvm.org/build.html<br />
<br />
lldb Linux buglist: http://llvm.org/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=lldb-linux&list_id=40756<br />
<br />
lldb-dev archives: http://lists.cs.uiuc.edu/pipermail/lldb-dev/<br />
lldb-commits archives: http://lists.cs.uiuc.edu/pipermail/lldb-commits/<br />
<br />
LLDB Reference Documentation: http://lldb.llvm.org/docs.html<br />
GDB commands in LLDB: http://lldb.llvm.org/lldb-gdb.html<br />
<br />
Code reviews with Phabricator: http://llvm.org/docs/Phabricator.html<br />
- This phabricator thing produces easy to read diffs so I can submit patches like this:<br />
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2013-July/002027.html<br />
- "arc diff" and "arc submit" are the two main commands.<br />
Warning: they can be a bit of a pain when working with multiple patches.<br />
<br />
Rad's working lldb branch: https://bitbucket.org/mikesart/lldb_branch<br />
- has a couple fixes not merged into lldb svn branch yet (largest is libedit 3.1).<br />
<br />
Rad's bugs/work list: https://bitbucket.org/mikesart/lldb_branch/issues?status=new&status=open<br />
<br />
I've set up two lldb enlistments:<br />
- Our working mercurial branch: ~/data/src/lldb.hg<br />
(tools/lldb is from our Mercurial branch)<br />
- Official Subversion branch: ~/data/src/lldb.svn<br />
(tools/lldb is from lld Subversion branch)<br />
<br />
Each branch looks like this on my machine:<br />
<br />
lldb.hg<br />
|<br />
`-- build<br />
|<br />
llvm<br />
|<br />
`-- tools<br />
|<br />
+-- clang<br />
|<br />
`-- lldb<br />
<br />
I test individual patches, submit, test official tree from lldb.svn, and work out of lldb.hg.<br />
<br />
#<br />
# Tools<br />
#<br />
<br />
cmake version 2.8.10.2<br />
ninja 1.3.3<br />
Mercurial Distributed SCM (version 2.6)<br />
svn, version 1.7.9 (r1462340), compiled Apr 6 2013, 21:23:46<br />
Clang 3.3 (http://linux-debugger-bits.blogspot.com/2013/07/clang-33-with-64-bit-ubuntu-1204.html)<br />
<br />
# Other useful tools:<br />
TortoiseHg Dialogs (version 2.8), Mercurial (version 2.6)<br />
meld 1.7.3<br />
CGDB 20130523 (cgdb built from http://cgdb.github.io/)<br />
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04<br />
<br />
#<br />
# internal patch to get lldb build warnings down (until these can be fixed).<br />
#<br />
<br />
Index: ../../cmake/modules/HandleLLVMOptions.cmake<br />
===================================================================<br />
--- ../../cmake/modules/HandleLLVMOptions.cmake (revision 186469)<br />
+++ ../../cmake/modules/HandleLLVMOptions.cmake (working copy)<br />
@@ -206,6 +206,12 @@<br />
if (LLVM_ENABLE_WARNINGS)<br />
append("-Wall -W -Wno-unused-parameter -Wwrite-strings" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)<br />
<br />
+ # option(RAD_EXTRA_CFLAGS "View the TERM environment var" OFF)<br />
+ if(RAD_EXTRA_CFLAGS)<br />
+ message(RAD_EXTRA_CFLAGS " environment variable is ${RAD_EXTRA_CFLAGS}")<br />
+ append(${RAD_EXTRA_CFLAGS} CMAKE_C_FLAGS CMAKE_CXX_FLAGS)<br />
+ endif(RAD_EXTRA_CFLAGS)<br />
+<br />
# Turn off missing field initializer warnings for gcc to avoid noise from<br />
# false positives with empty {}. Turn them on otherwise (they're off by<br />
# default for clang).<br />
<br />
#<br />
# My bash aliases for working with lldb project<br />
#<br />
# Can run following from lldb build directories:<br />
# ninja lldb<br />
# ninja check-lldb<br />
# To run individual tests, something like this from lldb/test directory:<br />
# ./dotest.py -C clang -v -t -f PlatformCommandTestCase.test_process_list<br />
<br />
# cd lldb_src_hg, etc. will work if "shopt -s cdable_vars" is set.<br />
export lldb_src_hg=~/data/src/llvm.hg/llvm/tools/lldb<br />
export lldb_src_svn=~/data/src/llvm.svn/llvm/tools/lldb<br />
export lldb_build_hg=~/data/src/llvm.hg/build<br />
export lldb_build_svn=~/data/src/llvm.svn/build<br />
<br />
path_append () { path_remove $1; export PATH="$PATH:$1"; }<br />
path_prepend () { path_remove $1; export PATH="$1:$PATH"; }<br />
path_remove () { export PATH=`echo -n $PATH | awk -v RS=: -v ORS=: '$0 != "'$1'"' | sed 's/:$//'`; }<br />
<br />
lldb_setenv_svn()<br />
{<br />
path_remove "/home/mikesart/data/src/llvm.hg/build/bin"<br />
path_prepend "/home/mikesart/data/src/llvm.svn/build/bin"<br />
}<br />
lldb_setenv_hg()<br />
{<br />
path_remove "/home/mikesart/data/src/llvm.svn/build/bin"<br />
path_prepend "/home/mikesart/data/src/llvm.hg/build/bin"<br />
}<br />
lldb_cmake_debug()<br />
{<br />
# run from lldb build directory to create ninja build files<br />
CC=clang cmake -DRAD_EXTRA_CFLAGS="-Wno-c99-extensions -Wno-sign-compare -Wno-four-char-constants -Wno-extended-offsetof -Wno-unused-function" -DCMAKE_CXX_FLAGS="-fcolor-diagnostics" -DCMAKE_BUILD_TYPE=Debug -C ../llvm -G Ninja<br />
}<br />
<div>
<br />
#<br />
# Faster debugging with gdb...<br />
#<br />
<br />
Gdb with lldb is super slow loading the symbols. Connecting can take ~15 seconds. I run this alias after building (takes about 19 seconds) and loading symbols with gdb drops to less than 1 second.<br />
<br />
mikesart@mikesart-rad:~/data/src/llvm.hg/llvm/tools/lldb/test$ type lldb_gdb_add_index<br />
lldb_gdb_add_index is a function<br />
lldb_gdb_add_index ()<br />
{<br />
echo gdb-add-index $(readlink -f $(dirname $(which lldb))/../lib/liblldb.so);<br />
time gdb-add-index $(readlink -f $(dirname $(which lldb))/../lib/liblldb.so)<br />
}<br />
<br />
mikesart@mikesart-rad:~/data/src/llvm.hg/llvm/tools/lldb/test$ cat ~/bin/gdb-add-index<br />
#! /bin/sh<br />
<br />
# Add a .gdb_index section to a file.<br />
<br />
# Copyright (C) 2010 Free Software Foundation, Inc.<br />
# This program is free software; you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation; either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# This program is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with this program. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
file="$1"<br />
dir="${file%/*}"<br />
<br />
# We don't care if gdb gives an error.<br />
/home/mikesart/data/src/gdb-7.6/gdb/gdb --data-directory=/home/mikesart/data/src/gdb-7.6/gdb/data-directory -nx --batch-silent -ex "file $file" -ex "save gdb-index $dir"<br />
<br />
if test -f "${file}.gdb-index"; then<br />
objcopy --add-section .gdb_index="${file}.gdb-index" --set-section-flags .gdb_index=readonly "$file" "$file"<br />
rm -f "${file}.gdb-index"<br />
fi<br />
<br />
exit 0</div>
<div>
<br /></div>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-44109623524460803542013-07-18T17:08:00.000-07:002013-07-18T17:14:33.710-07:00Linux pthread test app with lldbTesting some multithreaded debugging with lldb. We've got four issues to start looking at so far...<br />
<br />
1. Running "gdb -- blah", "b nanosleep", "r", will result in breaking on the nanosleep call.<br />
Running "lldb -- blah", "b nanosleep", "r", will result in breaking in the 'ret' instruction of the nanosleep call. So the break doesn't happen until after the sleep period.<br />
<br />
2. Doing a "gdb -- blah", "b main", "r", "b 71", "c", "info threads" will result in this on gdb:<br />
<br />
(gdb) info threads<br />
Id Target Id Frame<br />
3 Thread 0x7ffff65e2700 (LWP 5353) "thread_1" 0x00007ffff6ea384d in nanosleep () at ../sysdeps/unix/syscall-template.S:82<br />
2 Thread 0x7ffff6de3700 (LWP 5350) "thread_0" 0x00007ffff6ea384d in nanosleep () at ../sysdeps/unix/syscall-template.S:82<br />
* 1 Thread 0x7ffff7fd1740 (LWP 5220) "mainthrd" main (argc=1, argv=0x7fffffffdd08) at /home/mikesart/data/src/blah_pthreads/blah.cpp:71<br />
<br />
This on lldb:<br />
<br />
(lldb) thread list<br />
Process 5520 stopped<br />
* thread #1: tid = 0x1590, 0x000000000040113f blah`main(argc=1, argv=0x00007fff4ef17f28) + 495 at blah.cpp:71, name = 'blah, stop reason = breakpoint 2.1<br />
thread #2: tid = 0x15ff, 0x00007f92502d584d libc.so.6`__nanosleep + 45 at syscall-template.S:82, name = 'mainthrd<br />
thread #3: tid = 0x1600, 0x00007f92502d584d libc.so.6`__nanosleep + 45 at syscall-template.S:82, name = 'mainthrd<br />
<br />
The TIDs are hex and the thread names are wrong.<br />
<br />
3. On gdb, "thread apply all" gives us this:<br />
<br />
(gdb) thread apply all bt<br />
<b>Thread 3 (Thread 0x7ffff65e2700 (LWP 5353)):</b><br />
#0 0x00007ffff6ea384d in nanosleep () at ../sysdeps/unix/syscall-template.S:82<br />
#1 0x00007ffff6ea36ec in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:138<br />
#2 0x0000000000400f28 in thread_proc (arg=0x1) at /home/mikesart/data/src/blah_pthreads/blah.cpp:37<br />
#3 0x00007ffff79c0e9a in start_thread (arg=0x7ffff65e2700) at pthread_create.c:308<br />
#4 0x00007ffff6ed7ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112<br />
#5 0x0000000000000000 in ?? ()<br />
<b>Thread 2 (Thread 0x7ffff6de3700 (LWP 5350)):</b><br />
#0 0x00007ffff6ea384d in nanosleep () at ../sysdeps/unix/syscall-template.S:82<br />
#1 0x00007ffff6ea36ec in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:138<br />
#2 0x0000000000400f28 in thread_proc (arg=0x0) at /home/mikesart/data/src/blah_pthreads/blah.cpp:37<br />
#3 0x00007ffff79c0e9a in start_thread (arg=0x7ffff6de3700) at pthread_create.c:308<br />
#4 0x00007ffff6ed7ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112<br />
#5 0x0000000000000000 in ?? ()<br />
<b>Thread 1 (Thread 0x7ffff7fd1740 (LWP 5220)):</b><br />
#0 main (argc=1, argv=0x7fffffffdd08) at /home/mikesart/data/src/blah_pthreads/blah.cpp:71<br />
<br />
On lldb, this (no backtraces for sleeping threads):<br />
<br />
(lldb) bt all<br />
<b>* thread #1: tid = 0x1590, 0x000000000040113f blah`main(argc=1, argv=0x00007fff4ef17f28) + 495 at blah.cpp:78, name = 'blah, stop reason = breakpoint 2.1</b><br />
frame #0: 0x000000000040113f blah`main(argc=1, argv=0x00007fff4ef17f28) + 495 at blah.cpp:71<br />
frame #1: 0x00007f925023776d libc.so.6`__libc_start_main(main=0x0000000000400f50, argc=1, ubp_av=0x00007fff4ef17f28, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fff4ef17f18) + 237 at libc-start.c:226<br />
frame #2: 0x0000000000400b99 blah`_start + 41<br />
<b> thread #2: tid = 0x15ff, 0x00007f92502d584d libc.so.6`__nanosleep + 45 at syscall-template.S:82, name = 'mainthrd</b><br />
frame #0: 0x00007f92502d584d libc.so.6`__nanosleep + 45 at syscall-template.S:82<br />
<b> thread #3: tid = 0x1600, 0x00007f92502d584d libc.so.6`__nanosleep + 45 at syscall-template.S:82, name = 'mainthrd</b><br />
frame #0: 0x00007f92502d584d libc.so.6`__nanosleep + 45 at syscall-template.S:82<br />
<br />
4. gdb has these excellent thread-events (controllable via set print thread-events). Nothing like this in lldb yet.<br />
[New Thread 0x7ffff6de3700 (LWP 19270)]<br />
[Thread 0x7ffff6de3700 (LWP 19270) exited]<br />
<br />
<div class="gmail_extra">
Here is the test source.<br />
<br /></div>
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;">───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
1 #include <stdio.h>
2 #include <string.h>
3 #include <pthread.h>
4 #include <stdlib.h>
5 #include <unistd.h>
6 #include <sys/syscall.h>
7
8 __thread pid_t g_tls = -1;
9 __thread char g_threadname[32];
10
11 pid_t gettid()
12 {
13 return (pid_t)syscall(SYS_gettid);
14 }
15
16 void logf(const char *format, ...)
17 {
18 va_list args;
19 char buf[1024];
20
21 snprintf(buf, sizeof(buf), "'%s' [#%d LWP:%d 0x%lx] %s", g_threadname, g_tls, gettid(), pthread_self(), format);
22
23 va_start (args, format);
24 vprintf (buf, args);
25 va_end (args);
26 }
27
28 void *thread_proc(void *arg)
29 {
30 g_tls = (int)(intptr_t)arg;
31
32 logf("pthread_setname_np('%s')\n", g_threadname);
33 snprintf(g_threadname, sizeof(g_threadname), "thread_%d", g_tls);
34 pthread_setname_np(pthread_self(), g_threadname);
35
36 logf("sleep(5)\n");
37 sleep(5);
38
39 pid_t tid = gettid();
40 logf("pthread_exit(%d)\n", tid);
41 pthread_exit((void *)(intptr_t)tid);
42 return 0;
43 }
44
45 int main(int argc, char *argv[])
46 {
47 pthread_t threadids[256];
48 static const size_t max_threads = sizeof(threadids) / sizeof(threadids[0]);
49
50 size_t num_threads = (argc > 1) ? atoi(argv[1]) : 2;
51 if (num_threads < 2)
52 num_threads = 2;
53 else if (num_threads > max_threads)
54 num_threads = max_threads;
55
56 snprintf(g_threadname, sizeof(g_threadname), "mainthrd");
57 pthread_setname_np(pthread_self(), g_threadname);
58
59 printf("num_threads:%zu\n", num_threads);
60
61 for(size_t i = 0; i < num_threads; i++)
62 {
63 int err = pthread_create(&(threadids[i]), NULL, &thread_proc, (void *)(intptr_t)i);
64 logf("pthread_create:%d (%s) pthread_t:%lx\n", err, strerror(err), threadids[i]);
65 }
66
67 sleep(1);
68
69 for(size_t i = 0; i < num_threads; i++)
70 {
71 logf("Waiting for thread #%zu\n", i);
72
73 void *status = NULL;
74 int rc = pthread_join(threadids[i], &status);
75 logf("Thread #%zu rc:%d status:%d\n", i, rc, (int)(intptr_t)status);
76 }
77
78 printf("done.\n");
79 return 0;
80 }
</code></pre>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com1tag:blogger.com,1999:blog-8499503232098202820.post-19582875965191016682013-07-16T17:06:00.000-07:002013-07-16T17:06:55.395-07:00gdb catchpointsNot sure how the hell didn't know about this until now, but these gdb catchpoints are pretty nifty.<br />
<br />
<a href="http://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.html">http://sourceware.org/gdb/onlinedocs/gdb/Set-Catchpoints.html</a><br />
<br />
You can do something like "catch load libbfd.so" and you'll hit a breakpoint in dl-debug.c when that .so is loaded.<br />
<br />
(gdb) catch load libbfd.so<br />
Catchpoint 1 (load)<br />
(gdb) r<br />
Starting program: /home/mikesart/data/src/blah_dyldrendezvous_crash/build/blah<br />
hello world<br />
<br />
Catchpoint 1<br />
Inferior loaded /usr/lib/libbfd.so<br />
/lib/x86_64-linux-gnu/libz.so.1<br />
__GI__dl_debug_state () at dl-debug.c:77<br />
(gdb) bt<br />
#0 __GI__dl_debug_state () at dl-debug.c:77<br />
#1 in dl_open_worker<br />
#2 _dl_catch_erroroperate<br />
#3 in _dl_open<br />
#4 in dlopen_doit<br />
#5 in _dl_catch_error<br />
#6 in _dlerror_run<br />
#7 in __dlopen<br />
#8 in main<br />
<div>
<br /></div>
<div>
There are catchpoints for calls to exec, fork, syscalls, and signals that could all be useful as well.</div>
<div>
<br /></div>
<div>
I don't see anything like this in lldb - adding to the task list...</div>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-48467673065653135452013-07-16T12:26:00.003-07:002013-10-29T08:19:25.792-07:00Clang 3.3 with 64-bit Ubuntu 12.04Just documenting how I switch between various compilers on Linux with update-alternatives. I use update-alternatives, a tool to "maintain symbolic links determining default commands."<br />
<br />
1. Grab appropriate clang 3.3 binaries from: <a href="http://llvm.org/releases/download.html">http://llvm.org/releases/download.html</a><br />
<br />
2. Unpack somewhere. (I unpacked to my ~/data directory using atool -x).<br />
<br />
2. Install binaries with update-alternatives. For gcc 4.6 and clang 3.3, I did the following:<br />
<br />
# install gcc 4.6<br />
# "update-alternatives --install" takes a link, name, path and priority.<br />
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 100<br />
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.6 100<br />
sudo update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-4.6 100<br />
<br />
# install clang 3.3<br />
# "update-alternatives --install" takes a link, name, path and priority.<br />
sudo update-alternatives --install /usr/bin/gcc gcc ~/data/clang3.3/bin/clang 50<br />
sudo update-alternatives --install /usr/bin/g++ g++ ~/data/clang3.3/bin/clang++ 50<br />
sudo update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-4.6 100<br />
<div>
<br /></div>
<div>
3. I then use the following bash functions to switch compilers.</div>
<div>
<br /></div>
<div>
<div>
compiler_clang-3.3()</div>
<div>
{</div>
<div>
sudo update-alternatives --set gcc ~/data/clang3.3/bin/clang</div>
<div>
sudo update-alternatives --set g++ ~/data/clang3.3/bin/clang++</div>
<div>
sudo update-alternatives --set cpp-bin /usr/bin/cpp-4.6</div>
<div>
update-alternatives --display gcc</div>
<div>
update-alternatives --display g++</div>
<div>
update-alternatives --display cpp-bin</div>
<div>
}</div>
</div>
<div>
<br /></div>
<div>
<div>
compiler_gcc-4.6()</div>
<div>
{</div>
<div>
sudo update-alternatives --auto gcc</div>
<div>
sudo update-alternatives --auto g++</div>
<div>
sudo update-alternatives --auto cpp-bin</div>
<div>
update-alternatives --display gcc</div>
<div>
update-alternatives --display g++</div>
<div>
update-alternatives --display cpp-bin</div>
<div>
}</div>
</div>
<div>
<br /></div>
<div>
4. I also add clang and clang++ explicitly to my path in case something uses them explicitly.</div>
<div>
<br /></div>
<div>
<div>
mikesart@mikesart-rad:~/data/src/blah/build$ ll ~/bin/clang*</div>
<div>
lrwxrwxrwx 1 mikesart mikesart 50 Jun 12 14:12 ~/bin/clang -> ~/data/clang3.3/bin/clang</div>
<div>
lrwxrwxrwx 1 mikesart mikesart 52 Jun 12 14:12 ~/bin/clang++ -> ~/data/clang3.3/bin/clang++</div>
</div>
<div>
<br /></div>
<div>
<b>5 - 100. MAJOR WARNING</b>: Make sure you switch back to your default compiler before installing or updating pretty much anything. Various components like the NVIDIA driver will fail to build with anything but the system default, and then you're in for some good times.</div>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-9342969459228981702013-07-10T00:14:00.000-07:002013-07-10T08:49:21.414-07:00State of LLDB on LinuxI've had this question pop up a few times now. Can be summed up as "why is Rad/Valve working on LLDB on Linux - isn't it already done?" Some people get a bit aggressive about it:<br />
<div class="bbcode_container">
<div class="bbcode_quote">
<blockquote class="tr_bq">
<blockquote class="tr_bq">
<div class="quote_container">
Roberts then followed up with another Tweet, "To be more clear: RAD
is looking for developers to write debuggers. We are working on lldb on
Linux currently..."
</div>
</blockquote>
</blockquote>
</div>
</div>
<blockquote class="tr_bq">
Seriously? The giant's share of the work is coming from Apple. RAD
is either exaggerating their intent, talking out their ass, and or
both. What little they are working on is testing and bug tracking to
make sure LLDB is not broken on Linux. LLDB has been working on Linux
for nearly a year.
</blockquote>
Sometimes I wish I could Gong Show portions of the Internets.<br />
<br />
Many good folks have done a lot of wonderful work and made a lot of progress the past year on Linux LLDB. This includes four developers we've recently met at Intel, as well as several from Apple, FreeBSD, and others - but there is still a _lot_ to do before we can use LLDB to debug L4D2 and TF2. Or even LLDB. Or even a 32-bit version of printf("talking out our asses!");<br />
<br />
When we started working on this a couple months ago, you couldn't list currently running Linux processes or attach by process name. Major features like threading and split symbol support have just recently been added. One month ago you could not debug multi-threaded applications or step into system libraries with symbols or source.<br />
<br />
As of right now, you still can't load core files and debugging 32-bit Linux applications pretty much just doesn't work. We just started looking at the i386 test suite today.<br />
<br />
DWARF4 symbols (the default for gcc 4.8) do not work.<br />
<br />
Expressions can be shaky and backtraces could use some sweet, sweet lovin'.<br />
<br />
I'm tracking down an assert and crash loading the nss shared library right now. (See last blog post). <br />
<br />
Several tests in the test suite currently fail on 64-bit Linux.<br />
<br />
33 of 262 tests fail on 32-bit Linux.<br />
<br />
Linux LLDB has a tendency to hang at times, and I'm currently seeing some crazy long target load times.<br />
<br />
There is no remote debugging on Linux.<br />
<br />
For more, take a look at the current Linux lldb bug database:<br />
<br />
http://llvm.org/bugs/buglist.cgi?resolution=---&op_sys=Linux&query_format=advanced&component=All%20Bugs&product=lldb<br />
<br />
There was a good blog post about LLDB 3.3 recently on llvm.org that is well worth reading.<br />
<br />
http://blog.llvm.org/2013/06/lldb-33-and-beyond.html<br />
<br />
There is a lot to like about LLDB, and we have really enjoyed the community and working on it. There is also much to do before we can ditch gdb and use it fulltime. If any of this work sounds interesting, please jump in and help!Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com5tag:blogger.com,1999:blog-8499503232098202820.post-69228378044863107302013-07-09T11:28:00.000-07:002013-07-09T11:28:38.887-07:00r_debugLLDB is asserting and dying in DYLDRendezvous::UpdateSOEntries() and I got a core dump for it and the target it was debugging.<br />
<br />
I load the core dump for the target - it's crashing in _dl_debug_state() line in _dl_map_object_from_fd():<br />
<br />
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> 1040| /* Notify the debugger we have added some objects. We need to
1041| call _dl_debug_initialize in a static program in case dynamic
1042| linking has not been used before. */
1043| r->r_state = RT_ADD;
1044+> _dl_debug_state ();
1045| make_consistent = true;
</code></pre>
<br />
_dl_debug_state() is an empty function though.<br />
<br />
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> 70| /* This function exists solely to have a breakpoint set on it by the
71| debugger. The debugger is supposed to find this function's address by
72| examining the r_brk member of struct r_debug, but GDB 4.15 in fact looks
73| for this particular symbol name in the PT_INTERP file. */
74| void
75| _dl_debug_state (void)
76| {
77+>}
</code></pre>
<div>
<br /></div>
<div>
Why on earth would it crash there?</div>
<div>
<br /></div>
<div>
<div>
(gdb) disassemble _dl_debug_state</div>
<div>
Dump of assembler code for function __GI__dl_debug_state:</div>
<div>
0x00007fb123d9cb30 <+0>: int3</div>
<div>
=> 0x00007fb123d9cb31 <+1>: ret</div>
<div>
End of assembler dump.</div>
</div>
<div>
<br /></div>
<div>
Oh.</div>
<div>
<br /></div>
<div>
LLDB must have shoved the int3 in there, then it died and didn't remove the mess and the target went down. This is pretty slick though - this is how the debugger is notified that a new shared object is being loaded. Lots of details in elf/link.h that I'm going to start reading.</div>
<div>
<br /></div>
<div>
<a href="http://sourceware.org/ml/gdb/2000-q1/msg00193.html">http://sourceware.org/ml/gdb/2000-q1/msg00193.html</a></div>
<div>
<br /></div>
<div>
Sadly, loading the core file for lldb doesn't go so well...</div>
<div>
<br /></div>
<div>
BFD: Warning: /var/crash/core.internal-state.6.23639.mikesart-rad.1373391421 is truncated: expected core file size >= 339070976, found: 105598976.</div>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0tag:blogger.com,1999:blog-8499503232098202820.post-63516427097562108032013-07-08T16:24:00.001-07:002013-07-08T16:27:44.206-07:00Mixed mode disassemblyI was testing on 64-bit Linux with LLDB and this simple program, and ran into this bit of interesting gdb behavior I had never noticed before.<br />
<div>
<div>
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> 1| #include <stdio.h>
2| #include <stdlib.h>
3|
4| int main( int argc, char *argv[] )
5| {
6| int blah2[8192];
7| for(size_t i = 0; i < 8192; ++i)
8| {
9| blah2[i] = rand();
10| }
11| }
</code></pre>
<br />
Set a breakpoint on line 7 with LLDB, and get two locations:</div>
<div>
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> (lldb) breakpoint set -l 7
Breakpoint 2: 2 locations.
</code></pre>
<div>
<div style="color: #222222; font-family: arial; font-size: small;">
<br /></div>
With gdb, it sets one breakpoint:</div>
</div>
<div>
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> (gdb) b 7
Breakpoint 1 at 0x4007c9: file ~/data/src/blah2/blah.cpp, line 7.
</code></pre>
<br />
I spew out the disassembly with mixed source. LLDB and gdb look quite different. Took a second to figure out what's going on... gdb is moving assembly instructions to match them up with line numbers. It moved the four bold instructions up before the rand() call. Crazy!</div>
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> (gdb) disassemble /m main
Dump of assembler code for function main(int, char**):
5 {
0x00000000004007b0 <+0>: push rbp
0x00000000004007b1 <+1>: mov rbp,rsp
0x00000000004007b4: sub rsp,0x8020
0x00000000004007bb: mov DWORD PTR [rbp-0x4],0x0
0x00000000004007c2: mov DWORD PTR [rbp-0x8],edi
0x00000000004007c5: mov QWORD PTR [rbp-0x10],rsi
6 int blah2[8192];
7 for(size_t i = 0; i < 8192; ++i)
=> 0x00000000004007c9: mov QWORD PTR [rbp-0x8018],0x0
0x00000000004007d4: cmp QWORD PTR [rbp-0x8018],0x2000
0x00000000004007df: jae 0x400811
<b> 0x00000000004007f8: mov rax,QWORD PTR [rbp-0x8018]
0x00000000004007ff: add rax,0x1
0x0000000000400805: mov QWORD PTR [rbp-0x8018],rax
0x000000000040080c: jmp 0x4007d4 </b>
8 {
9 blah2[i] = rand();
0x00000000004007e5: call 0x400690 <rand@plt>
0x00000000004007ea: mov rcx,QWORD PTR [rbp-0x8018]
0x00000000004007f1: mov DWORD PTR [rbp+rcx*4-0x8010],eax
10 }
11 }
0x0000000000400811: mov eax,DWORD PTR [rbp-0x4]
0x0000000000400814: add rsp,0x8020
0x000000000040081b: pop rbp
0x000000000040081c: ret
</code></pre>
<br />
This is the straightforward disassemble call:<br />
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> (gdb) disassemble main
Dump of assembler code for function main(int, char**):
0x00000000004007b0 <+0>: push rbp
0x00000000004007b1 <+1>: mov rbp,rsp
0x00000000004007b4: sub rsp,0x8020
0x00000000004007bb: mov DWORD PTR [rbp-0x4],0x0
0x00000000004007c2: mov DWORD PTR [rbp-0x8],edi
0x00000000004007c5: mov QWORD PTR [rbp-0x10],rsi
=> 0x00000000004007c9: mov QWORD PTR [rbp-0x8018],0x0
0x00000000004007d4: cmp QWORD PTR [rbp-0x8018],0x2000
0x00000000004007df: jae 0x400811
0x00000000004007e5: call 0x400690 <rand@plt>
0x00000000004007ea: mov rcx,QWORD PTR [rbp-0x8018]
0x00000000004007f1: mov DWORD PTR [rbp+rcx*4-0x8010],eax
<b> 0x00000000004007f8: mov rax,QWORD PTR [rbp-0x8018]
0x00000000004007ff: add rax,0x1
0x0000000000400805: mov QWORD PTR [rbp-0x8018],rax
0x000000000040080c: jmp 0x4007d4 </b>
0x0000000000400811: mov eax,DWORD PTR [rbp-0x4]
0x0000000000400814: add rsp,0x8020
0x000000000040081b: pop rbp
0x000000000040081c: ret
End of assembler dump.
</code></pre>
<br />
LLDB looks like the below. The two bold instructions are where the breakpoint locations are. I think I'm going to keep the current LLDB behavior on this one. Although I am going to add the ability to lowercase my registers and get hex constants...<br />
<pre style="background-image: URL(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGJ3fLgV1AX2Kr0tXqPxBBvm0IGyFRanRtTaNS0B7gQY05i48BMU2hiCmJb7r-OY9LrKYlGeEvEbPcSwltWFR9cfCdDfEN9liab61tHqtjE1HLbEASXAmAQPyRWQ5DTDDcWJ9dGK7DLI4/s320/codebg.gif); background: #f0f0f0; border: 1px dashed #CCCCCC; color: black; font-family: arial; font-size: 12px; height: auto; line-height: 20px; overflow: auto; padding: 0px; text-align: left; width: 99%;"><code style="color: black; word-wrap: normal;"> (lldb) disassemble -m -n main
blah`main at blah.cpp:5
4 int main( int argc, char *argv[] )
5 {
6 int blah2[8192];
0x4007b0: push RBP
0x4007b1: mov RBP, RSP
0x4007b4: sub RSP, 32800
0x4007bb: mov DWORD PTR [RBP - 4], 0
0x4007c2: mov DWORD PTR [RBP - 8], EDI
0x4007c5: mov QWORD PTR [RBP - 16], RSI
blah`main + 25 at blah.cpp:7
6 int blah2[8192];
7 for(size_t i = 0; i < 8192; ++i)
8 {
<b> 0x4007c9: mov QWORD PTR [RBP - 32792], 0 </b>
0x4007d4: cmp QWORD PTR [RBP - 32792], 8192
0x4007df: jae 0x400811 ; main + 97 at blah.cpp:11
blah`main + 53 at blah.cpp:9
8 {
9 blah2[i] = rand();
10 }
0x4007e5: call 0x400690 ; symbol stub for: rand
0x4007ea: mov RCX, QWORD PTR [RBP - 32792]
0x4007f1: mov DWORD PTR [RBP + 4*RCX - 32784], EAX
blah`main + 72 at blah.cpp:7
6 int blah2[8192];
7 for(size_t i = 0; i < 8192; ++i)
8 {
<b>0x4007f8: mov RAX, QWORD PTR [RBP - 32792] </b>
0x4007ff: add RAX, 1
0x400805: mov QWORD PTR [RBP - 32792], RAX
0x40080c: jmpq 0x4007d4 ; main + 36 at blah.cpp:7
blah`main + 97 at blah.cpp:11
10 }
11 }
0x400811: mov EAX, DWORD PTR [RBP - 4]
0x400814: add RSP, 32800
0x40081b: pop RBP
0x40081c: ret
</code></pre>
</div>
Anonymoushttp://www.blogger.com/profile/16050560282362594132noreply@blogger.com0