> similar to retguard stack smashing detection. If you disassemble the
> whole hello`StgRun, somebody more knowledgeable might be able to tell us
> what's going on.

I disassembled the StgRun symbol, but it lacked any brk, which I spotted
at the end of the symbol before it while messing around, so I reran the
disassembler with all symbols but just grepped with context for StgRun
instead.

I've attach a text file of that output showing where StgRun is used, and
its definition along with 50 lines of context both ways.



> That's exciting. Now that you have the recipe reproduced more than once,
> maybe you can document it well enough for others to try following at
> home?

I've been keeping the commands in a shell script, though I was still
a bit surprised it worked to get to the same point first try. I was
running the commands manually, as the script didn't fetch the sources,
extract the sysroot, etc.

Apart from actually procuring the sysroot tarball to extract from, I've
cleaned it up so it does everything into a hopefully usable 292-line
script.

Most of that line count is from comments, arguments split up over many
lines, support for both ways of fetching sources, and the embedded
patchfile. You can, of course, read it and run things manually if you
want.

While, of course, the various commands have been tested, I haven't
actually run it as an integrated script (in either fetch mode).

Comment paragraphs starting with “NOTE:” mark out things which I'm
not sure whether are needed or not or where I don't know why they're
needed, or it doesn't make sense that they're needed (or inversely, that
they work).

It installs dependencies with pkg_add and fetches sources w/ Git by
default, or source tarball if $FETCH_TARBALL_SOURCES is set to 1.

It requires as its first argument a path to a gzipped sysroot tarball
from an OpenBSD/arm64 system with libiconv installed. I created mine
with /usr/lib, /usr/include, and /usr/local/{lib,include,bin}, though I
doubt any binaries are necessary.

Since the only package I had installed was libiconv, all I had in the
/usr/local/ directories were libiconv stuff, but if you have other stuff
installed, I think the following command should suffice:

tar czf sysroot.tar.gz /usr/lib /usr/include /usr/local/lib/*{iconv,charset}* /usr/local/include/*{iconv,charset}* /usr/local/bin/iconv

You don't need to be root (I didn't, on a very minimal VM). When
extracting them, it recreates the sysroot tree with the permissions of
the user running tar.

Since I had to make changes to the tree to get the build working, I
decided to do a Git-based build on my real machine to keep easier track
of any changes, so I'll just embed the output of my `git diff` into the
script, which it'll use to patch the sourcetree.

I've attached the script as well.



Cheers,
Habib

> On 11 Nov 2024, at 16:57, Greg Steuck <gnezdo@openbsd.org> wrote:
> 
> حبيب محمد الأمين محمد الهـاد <ha.alamin@gmail.com <mailto:ha.alamin@gmail.com>> writes:
> 
>> New progress update.
>> 
>> I got stage 1 and 2 to build together(!) in just 2 hours. As before,
>> stage 2 compiler seems to be copied.
> 
> That's exciting. Now that you have the recipe reproduced more than once,
> maybe you can document it well enough for others to try following at
> home?
> 
>> I was unable to use the stage 1 compiler to link aarch64 binaries, I
>> got:
>> 
>> ld: error: relocation R_AARCH64_ABS64 cannot be used against local symbol; recompile with -fPIC
>> 
>> When I reran with -v3, I manually ran each command it showed, and it
>> failed at the link stage with:
>> 
>> ld.lld: error: can't create dynamic relocation R_AARCH64_ABS64 against local symbol in readonly segment; recompile object files
>> with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the
>> output
> 
> -z,notext used to be necessary for i386. While it's weird that arm64
> requires this, we can probalby resolve this once we have anything
> working on arm64.
> 
>> 
>> I could see the commands contained -fno-PIC, but rerunning the commands
>> with -fPIC didn't work, so I added -Wl,-z,notext to them, and that
>> got rid of the errors, but when I tried to run the command on my
>> OpenBSD/arm64 VM, I got (whether run from $HOME or /usr/local/bin):
>> 
>> Trace/BPT trap (core dumped)
>> 
>> Running via lld, I get:
>> 
>> openbsd-arm64-host$ lldb /usr/local/bin/hello                                          
>> (lldb) target create "/usr/local/bin/hello"
>> Current executable set to '/usr/local/bin/hello' (aarch64).
>> (lldb) run
>> Process 65280 launched: '/usr/local/bin/hello' (aarch64)
>> Process 65280 stopped
>> * thread #1, stop reason = signal SIGTRAP
>>    frame #0: 0x00000007234d8040 hello`StgRun + 204
>> hello`StgRun:
>> ->  0x7234d8040 <+204>: brk    #0x1
>>    0x7234d8044 <+208>: ret    
> 
> I don't know what the epilogues on arm64 are like. This looks vaguely
> similar to retguard stack smashing detection. If you disassemble the
> whole hello`StgRun, somebody more knowledgeable might be able to tell us
> what's going on.
> 
> Thanks
> Greg

• hello-disasm-grep-StgRun.txt (9K)
• build-ghc-9.10.1-for-openbsd-arm64-on-openbsd-7.6-amd64.ksh (12K)