channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=11&d=2
12:16:43 <geist> dormito: yeah generally speaking yuo need to get the scheduler set up and get interrupts enabled very quickly prior to any threads needing to sleep or block
12:17:19 <geist> usually i have the kernel have phase 1 and phase 2, where phase 1 is try to get the scheduler and VM into a working state ASAP
12:17:28 <geist> and the last thign it does is start a thread that completes phase 2
12:17:37 <geist> which is usually where most drivers are initialized, and may need to sleep
12:25:09 <IDWMaster> Anyone here worked with the Zircon kernel at all?
12:26:22 * klange coughs in the general direction of geist
12:26:46 <geist> yes
12:27:30 <IDWMaster> I've been working on a patch to enable demand paging. I'm wondering if opening a ticket is enough to get someone to review it, or if I need to assign a reviewer to it?
12:27:41 <IDWMaster> I'm an outside contributor, so am not quite sure what the guidelines are for contribution.
12:27:43 <geist> you need to assign a reviewer
12:27:56 <geist> also there's a #fuchsia channel, you should ask there
12:28:01 <geist> and i'm on there too
12:28:10 <IDWMaster> OK.
02:11:55 <ybyourmom> https://www.youtube.com/watch?v=hmbUNF1Q4R8
02:12:13 <ybyourmom> Hey, I put some new shoes on and suddenly everything's right~
02:48:16 <geist> similarly: https://www.youtube.com/watch?v=MlQunle406U
03:53:36 <radens> how do I do a 32 bit register read in armv8 inline assembly?
03:53:43 <geist> w
03:53:54 <geist> %w0
03:54:00 <geist> vs just %0
03:56:23 <mischief> anyone got yacc experience? im looking for examples of interpreters using complex l-values in assignments
03:56:40 <mischief> such as arr[i] = value or o.member = value
03:56:54 <radens> geist: https://wandbox.org/permlink/2FWoTcSXCjIeNMRz
03:57:26 <radens> hm maybe I can only do a 64 bit read from system registers? But most gic registers are 32 bit.
03:57:31 <geist> yes, 64bit read
03:57:49 <geist> pretty much all system regs are 64bit
03:57:54 <radens> so then I need to do a static cast on return? That blows.
03:58:15 <geist> well, the compiler will almost assuredly generate no additional code
03:58:57 <Mutabah> mischief: Parse any expresison on the LHS, then sanitise after parsing?
03:59:17 <geist> anyway, the trick is the arch manual says that some control registers can be 32bit, but the instruction only allows for a 64bit register
03:59:30 <geist> so it says that any additional bits are ignored on write and RAZ on read
03:59:40 <klange> yacc is dead, everyone cool writes their parsers by hand these days
03:59:47 <geist> i actually looked this up the other day
04:00:01 <geist> radens: https://fuchsia.googlesource.com/zircon/+/master/kernel/arch/arm64/include/arch/arm64.h#36 are the macros i use, fwiw
04:00:53 <mischief> reports of yacc's death are greatly exaggerated
04:01:17 <radens> geist: I see what you're doing, but I don't like it. No offense.
04:01:22 <geist> and dont ask me about that formatting, that's what clang format does to inline asm
04:01:30 <geist> okey dokey
04:01:42 <geist> anyway, that's how it works
04:09:45 <radens> geist: I think I found a bug in fuchsia. According to the gic manual you only need to check the RWP bit for the GICD_CTLR and GICD_ICENABLER but you are using gic_wait_for_rwp after most register writes in the gicv3 code.
04:10:00 <radens> see 8.9.4 GICD_CTLR, Distributor Control Register
04:10:19 <radens> and kernel/dev/interrupt/arm_gic/v3/arm_gicv3.cpp circa line 116
04:10:31 <geist> cool, will file and bug and make someone look at it
04:10:46 <geist> it's likely, there arent a lot of real hardware with gicv3 yet, so that's mostly running against qemu
04:11:35 <radens> if I were qemu I wouldn't ever set that bit
04:11:50 <geist> yah
04:12:03 <radens> also, it does no harm to poll it too often, I think, but it will slow things down.
04:12:10 <geist> yah
04:12:14 <radens> those writes probably aren't cheap
04:19:21 <geist> yah bugs where you do more work than you need to are hard to catch
04:19:31 <geist> and hard to fix since you really need to prove that doing less is okay
04:20:23 <radens> yeah
04:20:45 <radens> and with a cheap arm component you may have to check that it does what the manual says
04:47:06 <radens> geist: how do you determine if an interrupt is group 1 or group 0?
04:48:15 <ybyourmom> If you're not the secure monitor, the answer is that you don't -- the monitor does that
04:48:35 <ybyourmom> The monitor sets up the groupings in the GIC
04:50:31 <radens> ybyourmom: so imagine I'm the hypervisor at el2. I want to configure most interrupts to reflect back into el1, and some to trap into el2. I need to set up the groupings then, right?
04:55:01 <ybyourmom> Lemme refresh myself
04:55:51 <ybyourmom> For GICv3, group0 can only be secure IRQs
04:56:11 <ybyourmom> And group1 can be either secure group 1 (handled in secure PL1)
04:56:17 <ybyourmom> Or nonsecure PL2
04:56:46 <ybyourmom> radens: In other words, the secure monitor will set up all IRQs that it intends to have you be able to handle, by putting them in group1
04:56:58 <ybyourmom> And you just need to re-inject them into PL1
04:57:58 <radens> — ARM expects these interrupts to be handled at Non-secure EL2 in systems using virtualization, or at Non-secure EL1 in systems not using virtualization
04:58:08 <radens> 4.6 in the manual
04:58:52 <ybyourmom> Right, so with Hyp mode, you will be given those IRQs at EL2
04:59:12 <radens> oh right, I misunderstood this.
04:59:24 <radens> I was confusing group 0 and group 1
04:59:34 <ybyourmom> The secure monitor is the guy who knows whether or not there is a hypervisor
04:59:41 <radens> okay, so I can safely assume that if I ever get an interrupt, it's group 0.
04:59:49 <radens> thanks.
04:59:59 <ybyourmom> Because it is the secure monitor/firmware which knows whether it loaded the "kernel" payload as hyp mode or supervisor mode
05:00:02 <ybyourmom> Np
05:18:00 <radens> wtf clang? https://hastebin.com/erasuriruy.cpp
05:27:43 <ybyourmom> I don't think GICD is a coprocessor
05:28:03 <ybyourmom> GICC, GICH and GICV should be architecturally accessible as coprocessors on ARMv8
05:28:19 <ybyourmom> But the distributor, ITS, etc, are memory mapped
05:29:24 <radens> ah, you're correct
05:53:00 <geist> right, essentially the parts of the GIC that are akin to x86's local apic are accessible by register
05:53:26 <geist> and the parts that are like ioapic (distributor, ITS) are memory mapped since they're implemented outside the core
05:57:52 <radens> is there something I need to do to enable the system register interface in qemu?
05:59:01 <radens> it's faulting with an undefined instruction when I try to read ICC_SRE_EL2 which enables the system register interface.
05:59:09 <geist> are you in EL2?
05:59:22 <radens> yes
05:59:30 <radens> I wrote to ttbr0_el2 long ago
05:59:44 <geist> i dont think so, but maybe there is a bit in the hypervisor control register?
06:00:27 <ybyourmom> You might need to enable the GIC CPU interface
06:00:55 <geist> we dont seem to access it in zircon, so i cant see if there was anythign in particular we had to do
06:02:05 <ybyourmom> Anybody on oceania who plays LoL in this channel?
06:02:10 <geist> oh wait, we do
06:02:13 <ybyourmom> PM me
06:02:27 <geist> well, we only seem to access the _el1 version
06:04:04 <radens> nah I still #UD with ICC_SRE_EL1
06:04:15 <radens> do I need to tell qemu to use the gic at all?
06:05:28 <ybyourmom> Gonna have myself a real good time
06:05:45 <ybyourmom> Or, bad time, have a great friday all~
06:05:59 <geist> unclear. we use the mrs/msr interface to read/write the sre_el1 register to enable the control register interface
06:06:23 <geist> via #define ICC_SRE_EL1 "S3_0_C12_C12_5"
06:06:43 <geist> it's one of the first things we do in the EL1 gic bringup
06:11:12 <geist> but it is a bit odd that we use the system reg interface to read the state and write it back
06:11:31 <geist> so i'm staritng to think it's just Always Enabled, and maybe qemu doesn't implement the _EL2 version
06:14:56 <geist> hmm, from grepping around qemu source, i only see references to icc_sre_el1
06:14:58 <geist> no _el2
06:17:43 <geist> oh no, it's there
06:18:13 <geist> looks like it's hard coded to 0xf
06:18:52 <geist> https://github.com/qemu/qemu/blob/master/hw/intc/arm_gicv3_cpuif.c#L2257
06:19:12 <geist> EL1 is set to 0x7 and hard coded too
06:47:06 <klange> re: the recent conversation about qr codes for crash dumps https://www.nayuki.io/page/creating-a-qr-code-step-by-step
06:47:53 <geist> they're pretty neat. you can stuff in a lot of data on the largest size
06:49:04 <geist> it is pretty genius, though
10:20:44 <MarcinWieczorek> Hello guys. Some time ago I implemented basic VFS and VFAT. I can open a file descriptor and assign it a mountpoint, let's say VFAT that has read/write functions and knows what to do with a file name. Now I need a devfs. My question is, should I tread every device as a separate mountpoint? Let's say I want stdout, so that would be a device that reads or writes from a queue or whatever. The thing is, I would
10:20:47 <MarcinWieczorek> have to implement such driver for every single device I would want to add, stdout, stderr. Could someone point me a direction? Also, my explanation is probably messy, cos I don't know what I'm doing myself
10:25:30 <blackandblue> hi geist
10:25:51 <blackandblue> geist, may I know if your upgrade from linux mint 17 to 18 and 18 to 19 were smooth? or you did clean installation
03:07:51 <abysslurker> o/
03:11:57 <MarcinWieczorek> \o
05:05:57 * geist yawns
05:11:18 * bauen1 yawns
05:18:16 * abysslurker yawns
05:41:18 * blackandblue literally just yawned after reading it
05:43:52 <geist> i've observed this too. the yawning thing seems like it can be transmitted by just the idea of yawning
05:54:18 <MarcinWieczorek> yawing as an official IRC protocol extension!
06:02:57 <jjuran> If you make a pitch to the standards committee, they might roll with it.
06:06:31 <mischief> they might also just reply with a yawn
06:10:58 <MarcinWieczorek> like with wooden peg dhcp
06:11:58 <mrvn> MarcinWieczorek: you should look into pipes
06:12:21 <MarcinWieczorek> hm?
06:12:41 <mrvn> jjuran: you will never get that approved. Every time you start discussing it they will yawn and fall asleep.
06:12:57 <mrvn> MarcinWieczorek: for your /dev/stdin, /dev/stdout, /dev/stderr
06:13:09 <MarcinWieczorek> oh, I asked that like half a day ago
06:13:52 <MarcinWieczorek> Yeah I could implement a pipe, which would be just a queue, right? But how to tie it with the VFS
06:13:58 <jjuran> mrvn: I think something got lost in translation
06:14:17 <MarcinWieczorek> also, char devices are not pipes, only in the case of standard io
06:16:08 <mrvn> MarcinWieczorek: /dev/stdin etc aren't char devices though. They are just references to whatever the process has open as stdin.
06:16:32 <mrvn> MarcinWieczorek: pipes will give you the right semantic and frequently stdin will even be a pipe
06:19:00 <MarcinWieczorek> my issue persists for their representation in VFS. How to make them look like files?
06:19:33 <mrvn> you need an interface for seekable and non-seekable files, although they overlap a lot.
06:21:37 <MarcinWieczorek> should just have a FS that holds read/write functions or other device related information instead of "file content"?
06:22:43 <mrvn> stdin needs a read function, stdout/stderr a write function.
06:23:15 <MarcinWieczorek> yeah but read/write are filesystem functions, a mountpoint has those, not a file
06:23:37 <mrvn> Then you have to change your setup. A device should have those too
06:23:55 <mrvn> First device you need is a /dev/console
06:24:07 <MarcinWieczorek> devices have them too
06:24:16 <MarcinWieczorek> But /dev/console is seen as a file
06:24:29 <MarcinWieczorek> how to make it look like one?
06:24:37 <mrvn> files need them too, provided from their FS.
06:25:14 <MarcinWieczorek> yeah so my devfs just keeps each file's aka device's read/write functions?
06:25:35 <mrvn> MarcinWieczorek: yes.
06:25:43 <MarcinWieczorek> makes sense
06:26:10 <MarcinWieczorek> What if I want to have devices outside /dev? some fsystems have pipes, right?
06:26:27 <mrvn> Consider using inheritance there. A lot of the time you can have generic functions that many devices can reuse.
06:26:47 <mrvn> No filesystem has pipes. They are kernel intern only.
06:27:02 <mrvn> just like no filesystem has devices.
06:27:23 <mrvn> There are device files that can be used to open a device though.
06:28:14 <mrvn> The metadata in the devcie file (major/minor under unix) let the kernel locate the right device. The name and location of the device file is irelevant.
06:28:31 <MarcinWieczorek> but in ext2 files can be devices
06:29:03 <mrvn> MarcinWieczorek: not really. device files. Which is just an inode that holds the name and the major/minor number.
06:29:27 <MarcinWieczorek> oh cool
06:29:45 <mrvn> It's more like a symlink to a device than a device itself.
06:32:00 <MarcinWieczorek> so let's say my major is X and implements a fifo, and X:0 X:1 X:2 are my stdin/out/err?
06:32:47 <mrvn> When you call open("/dev/sda") the VFS layer looks up the file in the FS. Then it sees that it has type S_ISBLK(m), takes the major/minor number from the entry and looks up the device in the kernel. The FS never handles anything of the device after the lookup.
06:33:11 <aalm> .roa
06:33:12 <glenda> - If that's what's written, then that's what's written.
06:33:28 <mrvn> stdin/out/err aren't devices.
06:33:42 <mrvn> And fifo has it's own type under unix.
06:34:42 <MarcinWieczorek> I understand
06:34:43 <MarcinWieczorek> Thank you
06:35:57 <mrvn> MarcinWieczorek: I would forget about all the magic /dev/ entries that link to /proc for now.
06:36:16 <MarcinWieczorek> That's what I would do too
06:36:28 <MarcinWieczorek> I don't have links
06:36:54 <mischief> MarcinWieczorek: perhaps you might like to read about plan 9
06:37:35 <mrvn> MarcinWieczorek: The /dev/stdin/... are hacks so that you can execute commands that require a filename instead of using stdin/... naturally.
06:37:39 <mischief> the papers are at http://doc.cat-v.org/plan_9/4th_edition/papers/ and they're pretty short
06:38:13 <MarcinWieczorek> I will
06:38:14 <mrvn> e.g. "cat /dev/stdin" if a plain "cat" wouldn't read stdin by default.
06:38:54 <aalm> exotic cat you've got there:]
06:39:10 <mrvn> aalm: you haven't seen my dog yet
06:39:11 <MarcinWieczorek> mrvn: what I really needed was the idea of major:minor which I didn't know
06:39:22 <MarcinWieczorek> It all became bright as daylight
06:40:08 <mischief> its a bit more elegant in 9p
06:40:15 <mischief> it has Qids for every file
07:33:09 <SopaXorzTaker> .help
07:34:10 <glauxosdever> .theo
07:34:11 <glenda> I don't think you understand what is being done here.
07:36:26 <aalm> aww
07:36:29 <aalm> .ken
07:36:29 <glenda> What is or is not implemented in the kernel represents both a great responsibility and a great power
07:37:01 <glauxosdever> Is ELTORITO! implemented?
07:37:05 <glauxosdever> .eltorito
07:37:16 <glauxosdever> (That should be in the bootloader actually, but anyway)
07:37:24 <aalm> it's busy booting
07:37:28 <aalm> .roa
07:37:28 <glenda> 65 Win or lose, there's always Hupyrian beetle snuff.
07:37:35 <aalm> oh, fast boot:]
07:38:07 <glauxosdever> mischief: Please add .eltorito -- if not, please run 3 instances of glenda just for tonight :-)
07:40:44 <glauxosdever> ..Someone should make a bot that detects a discussion suitable for ELTORITO!
07:41:01 <glauxosdever> Well, I can do that, if ops agree
07:42:01 <mischief> glauxosdever: again... contact the 9front maintainers about creating a suitable fortune database.
07:42:19 <glauxosdever> Ok, then run three instances of glenda at once
07:42:36 <mischief> no.
07:42:55 <glauxosdever> I want the impact of .theo to be thrice as strong
07:49:56 <glauxosdever> Ok, two questions: 1) Am I allowed to write a bot that detects eltorito and put it in here? 2) Because I can't actually run it on my machine (or my server account), could anyone assist in this by running it from their machine?
07:50:56 <glauxosdever> (That is, I can't run it all day round)
07:53:15 <bauen1> whats the purpose of .eltorito ?
07:53:37 <glauxosdever> ELTORITO! is an #osdev meme
08:41:01 <klys> .theo
08:41:01 <glenda> Yes you are wrong, and damn infuriating too.
09:44:05 <chrisf> fine osdevers, why is HPET not a clear win?
09:44:30 <geist> vs what precisely?
09:44:50 <chrisf> for existing systems, vs i suppose using the old PIT
09:45:06 <geist> vs old PIT i think it's a win across the board
09:45:15 <geist> vs local apic and TSC based time it's a bit less good
09:45:26 <geist> depending on the exact configuration of the machine
09:45:39 <chrisf> (or, vs whatever $popular_existing_os is doing if you hide the HPET from it)
09:46:13 <geist> if what you're talking about is specifically that windows favors using local apic vs HPET in certain configurations
09:46:17 <geist> as far as i know they do the Right Thing
09:46:23 <geist> as in, if TSC is superior they use it
09:46:43 <geist> and there's some silly cargo culty stuff where folks think HPET is superior and use a registry key to force it
09:47:11 <chrisf> broader context: i have a threadripper box on which i have to disable the HPET for windows to not be a choppy mess; and i want to cut through the "gamer advice" crap and understand what's actually going on :)
09:47:46 <geist> that's odd. generally speaking windws wont favor the HPET if the local apic has constant TSC, which threadrippers do
09:48:04 <geist> may be that multi die machines however favor HPET because the TSC may not be synced. i'd be a ltitle surprised
09:48:47 <lava> geist: i don't think that's the case on the multi-socket machines i've played with
09:48:49 <geist> from what i understand there was some gamer advice going around that HPET > *, and it may have been good for an arcane reason at a point in time, but since then most systems have picked up constant & invariant TSC
09:48:55 <geist> lava: same
09:49:13 <geist> but i can't 100% put my finger on it. i dont know any literature that definitively says that TSC will or wont be synced between cores or dies
09:49:44 <geist> i think practically speaking it is on at least workstation class machines
09:51:44 <be-p> I would like to better understand how do the linking of object file works(on windows right now). where should i read?
09:52:56 <chrisf> be-p: i liked ian lance taylor's blog series on linker guts
09:53:47 <be-p> ok thanks. i will look at it.
09:53:59 * bcos_ thinks geist was right - "because the TSC may not be synced"
09:54:37 <chrisf> bcos_: this is the old problem we used to have with 2S boxes, appearing again?
09:54:41 <be-p> chrisf: another question, I would like to statically add an object file into an already existing executable. what should i search for? i'm interested in this matter
09:55:20 <bcos_> chrisf: Maybe (might just be "Microsoft worried about the old problem in case")
09:57:00 <geist> and i say that because threadripper and being fucntionally two sockets
09:57:15 <geist> i'll take a look tonight if i remember. i just also installed windows 10 on my threadripper at home
09:57:22 <geist> should be able to check to see if it defaults to HPET or not
09:57:41 <geist> key is there is a single HPET, so from a 'what time is it' point of view it's not a bad source of truth
09:58:03 <geist> it runs at a reasonably high rate (14Mhz or so iirc), has a nice 32 or 64 bit counter, and is independent of how many cores you have
09:58:18 <geist> the main downside is its effectively supervisor only since it's memory mapped
09:58:25 <geist> and thus takes a syscall to get the current time
09:58:56 <geist> TSC when it is invariant/constant usually runs at a higher rate, up to the base frequency of the cpu in current designs, and is readable in user space via rdtsc
09:59:28 <geist> but you can only really use it if it is marked as invariant/constant TSC, so it doesn't change frequency as the cpu moves frequency and/or sleeps
09:59:33 <olsner> as I understand it, HPET was a win back when TSC varied in frequency and everything since it was faster than the *other* alternatives, but it's slower so you only want it if TSC can't be used
09:59:37 <geist> and if all the sockets/dies see the same TSC
09:59:48 <geist> olsner: that's what i understand too
10:00:11 <geist> anything modern made in the last 5 years or so seems to have invariant/constant TSC, so it's usable as a time base
10:00:50 <geist> running under a VM may or may fully expose TSC, too, so you sometimes have to fall back even on modern machines
10:01:40 <geist> so one thing i had read was when the meltdown KPTI stuff was rolled into windows a while back, a few of the tech sites reported much worse benchmarks for intel machines
10:01:55 <geist> turns out they had also been forcing HPET because it was a gamer cargo cult thing that everyone had been doing
10:02:25 <geist> which meant that the bazillion calls to get current time were now having to go through a KPTI syscall, and it affected benchmarks heavily
10:02:53 <geist> and others weren't seeing the same thing because windows was using TSC if you didn't override it
10:03:00 <geist> and thus no syscall
10:03:13 <mmu_man> https://m.g3l.org/@mmu_man/101003735368794666
10:03:23 <mmu_man> anyone with experience on the PEF format?
10:03:37 <mmu_man> had to fix, er, actually implement PEF output in binutils
10:08:51 <bcos_> mmu_man: GNU binutils includes support for Microsoft's "PE" object file format (although I think it's disabled for most Linux distros)
10:09:56 <be-p> I would like to statically add an object file into an already existing executable. should I implement linking if the object file refers to functions defined in shared libraries?
10:17:53 <bcos_> be-p: Erm. What kind of virus are you injecting into pirated software?
10:21:28 <mmu_man> oh, the loader section on this PEF file I have is actually the first in the file… does it mean it must be instanciable…
10:21:41 <mmu_man> bcos_: sorry, PEF != PE
10:21:47 <mmu_man> it's not even a COFF flavour
10:21:59 <mmu_man> it's the format used by old MacOS on PPC & 68k
10:22:52 <mmu_man> https://en.wikipedia.org/wiki/Preferred_Executable_Format
10:23:00 <mmu_man> odd, not even on osdev wiki
10:23:59 <mmu_man> and binutils has "some" support for PEF, namely broken reading and no writing at all, although it makes it appear like it writes. It just dumps the section contents without any header
10:24:17 <mmu_man> I spent a night writing basic support (no reloc/syms/exp/imports)
10:25:05 <be-p> bcos_: i'm just studying the matter, it is very exciting to learn how all that binaries work. i will probably invest in a malware analyst career more than injecting spywares in pirated software
10:26:02 <be-p> bcos_: things that i could actually do just using backdoorfactory as a script kiddie
10:27:30 <be-p> bcos_: you can also give me some indications or you were just wasting time replying?
10:31:42 <bcos_> be-p: What you're asking for isn't something "bizarre" that's not supposed to work; and you're asking in a channel for people writing their own operating systems (not a channel for compiler/linker developers)
10:31:59 <bcos_> *is something..
10:32:47 <mmu_man> you might have some more luck on ##binutils although it's very quiet
10:33:57 <be-p> i know but you all probably know how the linking is done and why for example in an object file, if i disassemble it the "call printf" becomes "e8 00 00 00 00" that is the equivalent of a call that has no offset set.
10:34:17 <be-p> anyway thanks mmu_man, you've proposed some solutions
10:35:29 <mmu_man> executables are already linked so a lot of info is gone at that point, trying to insert stuff inside is much harder. You might want to read some security related magazines.
10:36:19 <mmu_man> Things like the french MISC mag: https://connect.ed-diamond.com/MISC they often discuss those techniques
10:38:35 <mrvn> I always wanted to do that though to turn a dynamic elf into a static one. The runtime linker can basically do it so the info must be there.
10:41:16 <be-p> i hate the fact that this parts are quite obscure
10:47:53 <mmu_man> it depends, some parts are gone possibly, like relocations
10:48:00 <mmu_man> it depends on the format & other things
10:48:12 <mmu_man> anyway, back to PEF…
10:48:21 <mmu_man> why does it change the vma & start address
10:48:27 <mmu_man> (objcopy)
10:50:05 <mmu_man> printf '%x\n' $((0x00003224-0x00003174))
10:50:05 <mmu_man> b0
10:50:18 <mmu_man> yeah ok so it adds the file offset in the target file
10:50:27 <mmu_man> but didn't subtract the offset from the input file
10:51:11 <mmu_man> in theory I could just keep the original vma, as the PEF header is not meant to be kept anyway
10:51:49 <mmu_man> If I understand correctly, ELF is designed to be mapped entirely and direclty with the header kept, but I don't think PEF is
10:58:03 <mmu_man> ok, luckily our bootloader is built with PIC so I don't need to implement relocs :D
11:33:07 <mmu_man> hmm this looks wrong
11:33:09 <mmu_man> bfdsec->vma = section->default_address + section->container_offset;
11:33:10 <mmu_man> I wonder if the PEF support in binutils has ever actually been used at all
11:33:11 <mmu_man> :D