commit c3b3657cfbc88a306a442a35f61c8782d9f58e3f
parent 6456ee83760ec3987b37cd356b2e08e94d258c87
Author: hhvn <dev@hhvn.uk>
Date: Fri, 25 Nov 2022 16:24:01 +0000
Expand to gopher
Diffstat:
13 files changed, 177 insertions(+), 2 deletions(-)
diff --git a/gopher/eight-small-disks.jpg b/gopher/eight-small-disks.jpg
Binary files differ.
diff --git a/gopher/index.gph b/gopher/index.gph
@@ -0,0 +1,14 @@
+Welcome to hhvn's temporarily shitty gopherhole.
+
+Email: hhvn /AT/ hhvn /DOT/ uk
+IRC: hhvn at #hlircnet on irc.hlirc.net
+[1|hlircnet|/|hlirc.net|70]
+
+[I|Where's the old one? uhhhhh, here somewhere|eight-small-disks.jpg|server|port]
+[1|How about some code instead?|git/|server|port]
+
+Phlog:
+[0|2022-11-22 Tips for workflows involving makefiles and gdb|/plog/makefile_workflow.txt|server|port]
+
+[0|PGP key|/pgp.asc|server|port]
+[0|SSH key|/ssh.pub|server|port]
diff --git a/gopher/pgp.asc b/gopher/pgp.asc
@@ -0,0 +1 @@
+../pgp.asc
+\ No newline at end of file
diff --git a/gopher/phlog b/gopher/phlog
@@ -0,0 +1 @@
+../notes/
+\ No newline at end of file
diff --git a/gopher/ssh.pub b/gopher/ssh.pub
@@ -0,0 +1 @@
+../ssh.pub
+\ No newline at end of file
diff --git a/notes/makefile_workflow.txt b/notes/makefile_workflow.txt
@@ -0,0 +1,151 @@
+Title: Tips for workflows involving makefiles and gdb
+Date: 2022-11-22
+Updated: 2022-11-25 (valgrind)
+Tags: c make gdb ctags tags vim
+vim: set tw=77 cc=77 :
+
+# Some tips for making C projects more convenient.
+This integrates:
+- make
+- ctags (hence vim, or other editors that support tags)
+- gdb
+- valgrind
+
+Create a config.mk. This can keep your workflow related stuff in a seperate
+file from the makefile (that you'll probably track in git). This should then
+be included in the makefile.
+
+Of course, many projects will ship a config.mk already: usually these contain
+different CFLAGS, LDFLAGS, etc. tailored for different operating systems and
+architectures. They don't change often though, so I would recommend leaving
+your changes to a config.mk untracked, and manually adding changes you want
+to propagate elswhere. git add -p is your friend.
+
+## Now, what can you do in this file?
+
+1. Debug flags. A lot of C programs will allow you to define a macro that
+ makes them more verbose, amonst other things, making them ugly but easier
+ to debug.
+
+ A macro can be defined by passing the -D flag to a compiler. Usually flags
+ used by the compiler are stored in $(CFLAGS) so this can be done with:
+
+ CFLAGS += -DDEBUG
+
+ Something I find useful is replacing calls to exit() or similar on errors
+ with SIGTRAP:
+
+ #ifdef DEBUG
+ raise(SIGTRAP)
+ #else
+ exit(1);
+ #endif
+
+ SIGTRAP will cause the program to dump its core, which is useful as a
+ debugger can inspect it to see what happened to the program. However, as I
+ will show later in this file, it can also act as a breakpoint.
+
+2. Tagging. You can create a target that regenerates a tag file whenever source
+ is edited pretty quickly:
+
+ all: tags
+
+ tags: $(SRC)
+ ctags -R .
+
+ .PHONY: all tags
+
+ Make will run the ctags command whenever a dependency (in this case, all
+ the source files stored in $(SRC)) is changed. The ctags command will
+ recurse through the directory the makefile is, outputting all the tag
+ information to a file named, aptly, 'tags'. This file is then read by your
+ editor (if it's any good).
+
+3. Always running code via GDB.
+
+ There are two different ways I might like to run some code.
+
+ If I expect it to run fine, then I don't want to have to type 'run' in
+ GDB, and then 'quit' once it finishes running - I want to being able to
+ run it again quickly whenever any changes are made. In this case I use the
+ following target:
+
+ run: all # 'all' is usually a phony target that builds everything
+ # You may want to put proper tests here as well.
+ gdb ./$(BIN) -ex 'set confirm on' -ex run -ex bt -ex quit
+ # -ex tells gdb to run a command, these are run in order
+
+ .PHONY: test
+
+ If everything goes smoothly, once the program exits, gdb should too.
+ However, if something goes wrong, say a SIGSEGV, or perhaps a SIGTRAP that
+ was raised when exiting due to an error (remember earlier on?), it will
+ print a backtrace and allow you to start poking around.
+
+ Invoke this with `make run`
+
+ ---
+
+ In other cases though, you know that something is wrong, know roughly
+ where it happened (perhaps due to the backtrace triggered when you ran
+ `make test`) but need to figure out why. Here you'll probably want to set
+ a backtrace before the program is run, in which case this target may be
+ handy:
+
+ gdb: all
+ gdb ./$(BIN)
+
+ .PHONY: gdb
+
+ Yeah, it's pretty simple, but better than typing it out or grabbing it
+ from history. If you need to hand your program arguments, use --args. This
+ can be placed in a macro for convenience:
+
+ ARGS = --args whatever you want
+
+ gdb: all
+ gdb ./(BIN) $(ARGS)
+
+ And since it's a macro, you could append $(ARGS) to the 'test' target, and
+ now you only need to change it in one place.
+
+4. Valgrind. This is a pretty memory-leak checker (amongst other things),
+ though unfortunately it really slows down the program it's being run on.
+ Hence it's probably a good idea to put it in a seperate target:
+
+ VALFILE = valgrind.log
+ VALSUPP = valgrind-suppress
+ memcheck: all
+ @echo Outputting to $(VALFILE)
+ valgrind --tool=memcheck --leak-check=full \
+ --suppressions=$(VALSUPP) --log-file=$(VALFILE) \
+ ./$(BIN) $(ARGS)
+
+ By default, valgrind outputs to stdout. This can get pretty messy if your
+ program also outputs to stdout or otherwise uses the terminal. The
+ --log-file flag can be used to specify a file for valgrind to write to
+ instead. This is useful even if you're writing a GUI program as scrolling
+ up terminals (if your terminal even has scrollback) can be a pain compared
+ to opening up a file in less (or vim, which is pretty much always better
+ in my opinion).
+
+ Another thing this target does is provide valgrind with suppressions.
+ Creating another file is in order. You can suppress anything you want, but
+ one good usecase is suppressing anything other than your own program, i,e,
+ code run by libraries:
+
+ {
+ ignore_versioned_libs
+ Memcheck:Leak
+ ...
+ obj:*/lib*/lib*.so
+ }
+ {
+ ignore_versioned_libs
+ Memcheck:Leak
+ ...
+ obj:*/lib*/lib*.so.*
+ }
+
+ An unfortunate side-effect of this is that any callbacks that you provide
+ to the library won't be checked.
diff --git a/style.css b/style.css
@@ -1 +0,0 @@
-index.css
-\ No newline at end of file
diff --git a/index.css b/www/index.css
diff --git a/www/pgp.asc b/www/pgp.asc
@@ -0,0 +1 @@
+../pgp.asc
+\ No newline at end of file
diff --git a/robots.txt b/www/robots.txt
diff --git a/www/ssh.pub b/www/ssh.pub
@@ -0,0 +1 @@
+../ssh.pub
+\ No newline at end of file
diff --git a/www/style.css b/www/style.css
@@ -0,0 +1 @@
+index.css
+\ No newline at end of file
diff --git a/ytem.html b/www/ytem.html
