Breakpoints on inlined functions
I just committed a patch that makes GDB able to set breakpoints on inlined functions by name.
GDB neat things #1
tb for short) is exactly like
break except that the breakpoint it sets is deleted when it’s hit.
start runs the debugged program until the start of the main procedure. It’s equivalent to
tbreak main followed by
Little things for sure, but they save typing.
Working on gdb
For future reference, and because I keep forgetting things, here is how I work on gdb:
mkdir /somewhere/to/work cd /somewhere/to/work git clone ssh://sourceware.org/git/archer.git src cd src git remote add gdb git://sourceware.org/git/gdb.git
masterbranch to the correct place. The real one is in the GDB repo, but there’s an old one in Archer that is no longer used. Open
/somewhere/to/work/src/.git/configin your favourite editor and change
remote = originto
remote = gdbin the
[branch "master"]section. Then probably do a
git pullto fetch the actual code you’ll be working on.
git branch --track archer-gbenson-lazy-skip-inline-frames gdb/master git checkout archer-gbenson-lazy-skip-inline-frames
mkdir /somewhere/to/work/build cd /somewhere/to/work/build CFLAGS="-g -O0" ../src/configure --with-separate-debug-dir=/usr/lib/debug make
make check >& build-20110921-3.log diff -u baseline-20110919.log build-20110921-3.log | gdbtestdiff
cd /somewhere/to/work/build/gdb/testsuite runtest TRANSCRIPT=1 ../../../src/gdb/testsuite/gdb.opt/inline-cmds.exp gdb ../gdb
set prompt (top-gdb) b internal_error r -nx
Ok, I think that is enough for now.
A couple of months ago I switched from the OpenJDK team to the GDB team. I’ll no doubt write something here about what I’m doing soon (ie within the next year or so) but in the meantime if you would like to apply for my old job at the awesomeness that is Red Hat then please click this link.
Andrew Hughes pointed out yesterday that the ARM interpreter and JIT are slated for removal in IcedTea6-1.11 unless someone steps up to maintain it. Currently there’s only one place where the all information about what’s required is collated—inside my head—so I thought I’d better write it up before I start forgetting. It’s entirely possible the interpreter will be removed, but it’s also possible that someone will end up trying to resurrect it months or years down the line. If you are that person and you are reading this then you owe me a beer ;)
“[In the ARM code]
last_Java_sp is set to the address of the top Zero frame wherever the frame anchor is set up. It needs changing such that
last_Java_sp is set to
thread->zero_stack()->sp() (and the new field
last_Java_fp gets set to what
last_Java_sp used to be set to).”
“I have had to change the calling convention within Zero and Shark. All method entries (the C function that executes the method) now return an integer which is the number of deoptimized frames they have left on the stack. Whenever a method is called it is now the caller’s responsibility to check whether frames have been deoptimized and reenter the interpreter if they have.”
The third change, currently in progress, reverts the last commit by the ARM code’s author, Ed Nevill: fix for fast bytecodes with ARM/Shark. This piece of code was accidentally incorporated in one of the webrevs when Zero was upstreamed, and isn’t conditionalised correctly. It can cause problems when the ARM code is not present, and there’s no neat fix. Given that the ARM code has been broken for five days shy of a year now I’ve asked for it to be removed from OpenJDK. This is Sun bug 7030207. If the ARM code is resurrected, this patch will require reinstating (with more specific conditionalisation please!)
The fourth change, currently in the future, is JSR 292. Explicit method handle stuff should just work–it’ll be handled by Zero–but the ARM interpreter and JIT will need updating to support three new instructions:
fast_aldc_w. The latter two are internal instructions, in case you wondered why you’d never heard of them before!
Ok, that is all.
I just discovered that the ARM-specific interpreter stuff that Ed Nevill wrote (and then abandoned) last year has a hack that disables it when run with
-XX:+PrintCommandLineFlags. I guess this is one problem when you have 6,000 lines of assembler nobody understands: you don’t know what secret weird shit is buried in there.
JSR 292 and Zero
Maybe you’ve heard about JSR 292: Supporting Dynamically Typed Languages on the Java™ Platform? Well, it’s VM changes, and slated for OpenJDK 7 so I figured I ought to take a look at it before it suddenly appears and breaks Zero all over the place.
I’ve been working on it for a couple of weeks now over in the old Shark forest. It’s by no means stable, but if you want to have a play with it then here’s how:
hg fclone http://hg.openjdk.java.net/jdk7/hotspot-comp cd hotspot-comp export ALT_JDK_IMPORT_PATH=/path/to/some/existing/jvm export ALT_BOOTDIR=$ALT_JDK_IMPORT_PATH export DISABLE_NIMBUS=true export ALLOW_DOWNLOADS=true . jdk/make/jdk_generic_profile.sh make
hg fclone http://icedtea.classpath.org/hg/shark
Makefilein there, changing
JAVADIRto point to the JVM you just built.
JUNITJARto point to a JUnit 4 jarfile. The location there is where the Fedora
junit4package puts it, so if you have that installed you should be ok.
x86_64then you’ll need to edit
ZERO_ARCHFLAGto appropriate values for your system.
If you got your editing right it’ll build a new HotSpot, and create a copy of the JVM you built with the new HotSpot dropped in. It’ll then run the OpenJDK 7 JSR 292 unit tests on it.
They’ll fail, of course. Currently there’s no support for
invokedynamic yet: I’m still working on the method handles code that underpins it. Method handles look like ordinary methods, except when you call a method handle the VM is presented with a chain of transformations that need applying to the call’s arguments and return value to translate between what the caller supplied and what the eventual callee is expecting. The bad news is that there are some 40 (!) different transformations, of which I’ve implemented maybe 15. The good news is that (I think!) I’ve figured out the framework of it all, so now it’s mostly a case of run the code, read the “unimplemented” message it spits out, and implement the thing it was complaining about. Just like the old days :)
Shark now in OpenJDK 7
It’s taken a while, but all the pieces of Shark’s build system finally percolated through into an OpenJDK 7 release (build 112, released on October 1). Sadly a couple of HotSpot interfaces changed in the interim so you need to grab this changeset to get it working. We’ll get there eventually!
Shark build passes TCK
An IcedTea build of OpenJDK using Shark passed the Java SE 6 TCK today. Fedora 12, x86_64, LLVM 2.6, icedtea6-7674917fa451. Dr Fun is here!
Zero and Shark in IcedTea
Over the past few months I’ve been working on Shark in it’s own forest. This has allowed me to track upstream HotSpot (and the goal is to upstream Shark, so it’s the correct place to base it) but it’s meant that the Shark (and Zero) in IcedTea6 are old. I’m trying to update Zero and Shark in Icedtea6, but it’s a nightmare.
Zero in IcedTea6 has the ARM interpreter which can’t go upstream. Upstream has all the JSR 292 stuff which can’t go downstream. Between these two are fixes that need synchronizing, in both directions. One of the fixes, 6939182 (aka PR icedtea/324) requires the ARM interpreter to be updated before it can be committed, so that needs keeping separate… except that the changes to Shark to support that one are pretty invasive and hard to strip out.
It’s a real mess. I’m pretty close to giving up on it.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!