Log | Files | Refs

commit c3b3657cfbc88a306a442a35f61c8782d9f58e3f
parent 6456ee83760ec3987b37cd356b2e08e94d258c87
Author: hhvn <dev@hhvn.uk>
Date:   Fri, 25 Nov 2022 16:24:01 +0000

Expand to gopher

Agopher/eight-small-disks.jpg | 0
Agopher/index.gph | 14++++++++++++++
Agopher/pgp.asc | 2++
Agopher/phlog | 2++
Agopher/ssh.pub | 2++
Anotes/makefile_workflow.txt | 151++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Dstyle.css | 2--
Rindex.css -> www/index.css | 0
Awww/pgp.asc | 2++
Rrobots.txt -> www/robots.txt | 0
Awww/ssh.pub | 2++
Awww/style.css | 2++
Rytem.html -> www/ytem.html | 0
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