<geist>
Hammdist: to be clear, are you in arm64 or arm32?
<Hammdist>
pretty sure it's 64
<geist>
well, you have to know that 100% or you will not get past the first instruction
<Hammdist>
I've executed some instructions. but something is wrong with the C environment and it might be lack of a proper stack. so I'm trying now to figure out how to allocate space for a stack in the linker script
<geist>
re: your previous link it's because you were putting those in the output args, instead of input
<geist>
oh you can just allocate a stack as a global
<geist>
i wouldn't bother doing it in a linker
<Hammdist>
oh I see
<geist>
or you can do it as .data and a label in asm
<geist>
as far as needing to zero the stack, you dont have to preinitiailize it
<geist>
just need to have some space for the C code to do work
<Hammdist>
sure, makes sense
<geist>
that aside, i assume the godbolt thing was just an example, because you really dont want to futz with the stack pointer inside inline asm. you probably want a start.S and some startup asm code that puts things in order before branching into C/C++
<heat>
i tried to help but he likes his linux frankenstein very much
<heat>
so /shrug
<geist>
yeah i didn't read the full backlog
<heat>
btw i asked you but you didn't answer, arm64 without the mmu on is fully uncached right?
<geist>
the I and D cahce bits are still controllable in the SCTLR and iirc icache can be enabled and used
<geist>
but if you turn the D cache on it will treat all pages as uncached, yes
<geist>
it's basically what is the cache parameters of the one big large implicit page that covers all of physical space
<geist>
and i forget, but it's some variant of uncached
<heat>
oh so icache works but dcache doesnt?
<geist>
TL;DR yes
<heat>
yeah makes sense
<heat>
there's no MTRR equivalent in arm64
<geist>
yah
<geist>
but since the icache can work it's not too bad, because without icache the cpu will run at like 10mhz equivalent since it'll stall on every instruction
<geist>
though it may still limit what it can prefetch into, etc
<Hammdist>
so the MMU is definitely off I got the serial printout of the SCTLR register. yet it still always reads 5 from the serial port status register
<Hammdist>
I tried invoking a linux function that is intended to invalidate the data cache but it didn't help anything
<heat>
maybe you're driving the hardware wrong
<Hammdist>
lol it's a serial port
<geist>
oh you wouldn't believe how easy it is to drive a serial port wrong
<Hammdist>
anyways the characters I send echo all right - if I put in sleeps. but I have no way to tell what the queue fill is
<geist>
what does 5 mean in the status register?
<Hammdist>
ready ready on rx, tx empty
<geist>
is this on emulation?
heat has quit [Quit: Client closed]
<Hammdist>
no this is on a physical board
<geist>
ah, then you're right, that's probably not correct
<geist>
on an emulator it may act like it's infinitely fast, and thus instantly say tx is empty
<Hammdist>
makes sense. but if I print A, B, A, B as fast as possible I get runs of As and Bs
heat has joined #osdev
<geist>
yep, that sounds like a caching issue
<geist>
i have no idea what you're doing, but probably you're accessing the registers via a cached page
<Hammdist>
possibly. but I don't know why the hardware should feel there is a byte ready to read when I'm not sending anything to it through screen terminal
<geist>
if youre reading stale/cached/etc data from the status register then it doesn't matter, ecause you're not seeing reality
<geist>
*or* your code is wrong and you're reading the wrong register
<geist>
or both
<Hammdist>
I thought about the wrong register angle. I use the same struct definition as linux, and it would appear that the registers are 4-byte spaced but I would expect them to be 8-byte spaced on aarch64. not sure
<geist>
they are 4 byte spaced on all arches
<Hammdist>
ah hm
<geist>
the cpu architecture wont change the layout of hardware
terminalpusher has quit [Remote host closed the connection]
<geist>
if you're accessing it via a C structure you also have to make sure you go through volatile pointers and whatnot so the compielr doesn't cache it
<geist>
there are lots of ways to mess this up, need to be very careful
<Hammdist>
yeah the fields are marked volatile
<Hammdist>
I could try inserting one of those asm volatile memory barriers
<geist>
you shouldn't need that, but make sure the struct is properly aligned, fields are in the right place, etc
gildasio has quit [Ping timeout: 240 seconds]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bnchs is now known as Cindy
sortie has quit [Ping timeout: 245 seconds]
TheCatCollective has joined #osdev
MiningMarsh has quit [Ping timeout: 260 seconds]
CaCode_ has joined #osdev
netbsduser` has quit [Ping timeout: 246 seconds]
CaCode has quit [Ping timeout: 260 seconds]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
[_] is now known as [itchyjunk]
valshaped7424 has quit [Quit: Gone]
SGautam has quit [Quit: Connection closed for inactivity]
valshaped7424 has joined #osdev
Hammdist has quit [Quit: Client closed]
stolen has joined #osdev
Hammdist has joined #osdev
netbsduser` has joined #osdev
<heat>
EBUSY (Linux only) This may be returned by dup2() or dup3() during a race condition with open(2) and dup().
[itchyjunk] has quit [Remote host closed the connection]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
netbsduser` has quit [Ping timeout: 260 seconds]
<heat>
oh wow
<heat>
linux F_GETFD is not POSIX compliant
<heat>
or better, it kind of is? but it's racy too
SGautam has joined #osdev
m3a has quit [Ping timeout: 246 seconds]
netbsduser` has joined #osdev
<Hammdist>
how do I turn an arm64 elf into an arm64 "Image" file?
<heat>
objcopy to binart
<heat>
binary*
<Hammdist>
(I ditched linux and copied some files from Onyx instead, wanting to see if this works better)
<SGautam>
As in docker image?
<heat>
no
<heat>
Hammdist, see KERNEL_REQUIRES_FLATTENING in kernel/Makefile
<SGautam>
Ah, so a flattened ELF is called an "image"?
<heat>
no
<heat>
this is linux terminology
<heat>
x86 has bzImage (compressed flat kernel binary), arm64 has Image (uncompressed flat kernel binary)
<SGautam>
Essentially what does flattening do? I'm guessing it autofills the entries in the symbol tabl all relative to origin of program (absolute address like 1MB).
<heat>
no
<heat>
flattening essentially maps your image's address space into a single file, all binary, no headers
<heat>
lets say you have .text at 1MB (512KiB size), .data at 2MB, .bss right after .data
<SGautam>
oo
<heat>
you'd get a single binary file, .text at position 0, .data at position 2MB, .bss is not even in the file (if last in all the sections)
<heat>
erm, sorry, .data at position 1MB
<heat>
so the hole between .text and .data there (since .text is 512KiB but conceptually in virtual addressing, its 1MiB) is in the file, all 0s
<heat>
and you don't have symbols, you don't have file headers, nothing, whatever is loading needs to just know where the binary is expecting to get loaded
<heat>
(and the binary needs to Just Know where it's going to get loaded)
<Hammdist>
seems the image is rejected by kexec. will look a bit into the kexec source code see what it expects
netbsduser` has quit [Ping timeout: 256 seconds]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<heat_>
<heat> check if the header is right
<heat_>
<heat> it should expect a standard arm64 "linux" image, and that should be close to what you have
<Hammdist>
it seems the "magic" constant is off by one word
<Hammdist>
I think code 1 unused should be a .long, not a .quad
<heat_>
oh, good catch
<heat_>
funny that qemu still loaded it lol
<Hammdist>
well now it loads but there is no serial output from my program. will try and investigate to see where it gets stuck tomorrow
<heat_>
note that after the MMU is up you *cannot* just write to serial
<heat_>
you need to map it
<Hammdist>
ah. noted
<heat_>
unless you map everything uncached, which you could probably do as an experiment
<heat_>
also, check if you're in EL2, that code doesn't work with EL2 and needs to drop to EL1
netbsduser` has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
netbsduser` has quit [Ping timeout: 248 seconds]
bgs has joined #osdev
heat_ has quit [Ping timeout: 256 seconds]
goliath has quit [Quit: SIGSEGV]
Hammdist has quit [Quit: Client closed]
goliath has joined #osdev
bgs has quit [Remote host closed the connection]
Harriet has quit [Quit: K-Lined]
Harriet has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
Left_Turn has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
xvmt has quit [Read error: Connection reset by peer]
xvmt has joined #osdev
xvmt has quit [Read error: Connection reset by peer]
xvmt has joined #osdev
GeDaMo has joined #osdev
gog has quit [Ping timeout: 260 seconds]
SGautam has joined #osdev
gog has joined #osdev
Left_Turn has quit [Ping timeout: 246 seconds]
Left_Turn has joined #osdev
Hammdist has joined #osdev
Hammdist has quit [Quit: Client closed]
gildasio has joined #osdev
<mcrod>
hi
Turn_Left has joined #osdev
<gog>
hi
Left_Turn has quit [Ping timeout: 246 seconds]
<mcrod>
gog may i hug you
<gog>
yes
* mcrod
hugs gog
* gog
hug mcrod
* vdamewood
gives gog a fishy
* gog
chomp fishy
danilogondolfo has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
zxrom has quit [Quit: Leaving]
zxrom has joined #osdev
MiningMarsh has joined #osdev
[itchyjunk] has joined #osdev
<mjg>
got a great OS name
<mjg>
MENIX
SGautam has joined #osdev
<mjg>
albeit amerikkans may try to pronounce it the same way as minix
<bslsk05>
redirect -> www.reddit.com: Reddit - Dive into anything
<mjg>
there can be only one?
<gog>
i've never defeated anybody in combat :(
<mjg>
i'm guessing it was not... MORTAL COMBAT :rimshot:
phoooo has joined #osdev
dude12312414 has joined #osdev
<Hammdist>
so I am building an elf with "-g Os" and then converting it to bin format. I can boot the bin in qemu but not the elf. when I load the elf into gdb-multiarch it does not manage to show any symbols, however. platform is aarch64. when I objdump the elf I do see some debug sections
<Hammdist>
"-g -Os"
phoooo has quit [Quit: Client closed]
<Hammdist>
ah I just stepped into some code with a symbol
<Hammdist>
it's trying to jump to the virtual address of an asm target called .mmu_enabled, but qemu/gdb shows nothing is there (all zeroes)
Jari-- has joined #osdev
pch has joined #osdev
eddof13 has joined #osdev
<Hammdist>
holy cow I fixed it. at least in qemu. it was changing PHYS_BASE from 0x80000 to 0
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Hammdist>
so now I try to map the serial port. I add `third_level[511] = 0xff130000U | prot_device;` but where does that get mapped in memory is the question?
frkazoid333 has quit [Ping timeout: 246 seconds]
frkzoid has joined #osdev
<Hammdist>
well blast. it works fine in qemu but not on the board
<GeDaMo>
Solution: port qemu to work on the board :P
<zid>
did I watch ep 3 of foundation or not I don't remember
dutch has quit [Quit: WeeChat 4.0.2]
frkzoid has quit [Ping timeout: 248 seconds]
dutch has joined #osdev
<zid>
no, thankfully so spending 2 minutes unraring was worth
<heat_>
mjg, you didn't tell me if the test sucked :(
<sham1>
Yes
frkazoid333 has joined #osdev
gildasio has quit [Ping timeout: 240 seconds]
eddof13 has joined #osdev
<mjg>
heat_: it mostly does
<mjg>
your open/close rate is not fast enough to sensibly test ths
<mjg>
similarly fstat is one expensive way here
<gog>
nothing should be a file
<gog>
files are fucking slow and fragile and stupid
<bslsk05>
github.com: No prompt or text · Issue #1 · RelativisticMechanic/CRTerm · GitHub
<SGautam>
essentially
<zid>
full decs of every type
<gog>
just flat unbounded bytes
<gog>
unbounded arrays of bytes
<SGautam>
on NVIDIA GPUs this works: vec4 some_function(in sampler2D texture, ...) { ... vec4 col = texture(texture, uv.xy); }
<zid>
how do I perform operations like saving
gog has quit [Quit: Konversation terminated!]
<SGautam>
NVIDIA's GLSL compiler is able to differentiate between sampler2D texture and texture() function
<SGautam>
But it fails on AMD GPUs.
<SGautam>
Isn't that cool?
<zid>
whether that should work or not is part of the spec
<SGautam>
hm yea
<zid>
fairly sure
<SGautam>
its probably UB
<zid>
shadowing is mean
<SGautam>
but still, it seems like NVIDIA's compiler is more robust for sure
<zid>
robust is often a bad thing
<zid>
I could easily write that accidentally as a bug, and not notice, etc
<zid>
There's a reason -Wshadow exists for C
<zid>
despite being explicitly allowed
<SGautam>
hm true
<SGautam>
I'd usually expect for some reason for compilers to immediately figure out which identifier refers to what tho
<zid>
yea it just goes by the rules, or 'whatever the code happens to decide' if IDB/UB
<zid>
It already supports that kind of polymorphism, so it's not surprising it doesn't error at declaration time
<puck>
SGautam: "Otherwise, within one compilation unit, a declared name cannot be redeclared in the same scope; doing so results in a redeclaration error"
<puck>
*but*
<puck>
"The built-in functions are scoped in a scope outside the global scope users declare global variables in"
<puck>
so it shouldn't work
<puck>
you're allowed to in sampler2D texture, but you're not allowed to call it then
<SGautam>
so, NVIDIA has overimplemented a feature.
<puck>
it's a subtle detail tho
<SGautam>
"overimplemented" is that a word?
<zid>
It's just sort he natural, it's a polymorphic sort of env, so it looks for 'texture that is a function taking two floats' and finds one
<zid>
err a samper2d and a float
<zid>
and then looks for 'texture that is a sampler2d' and finds one
<puck>
zid: not entirely
<zid>
you'd have to go out of your way to make it fail imo
<zid>
and support things like making shadowing illegal
<zid>
is this core profile or compat?
<puck>
zid: you can have >1 function with the same name, with attribute overloading, but you cannot redeclare it as a variable or a structure type
<puck>
i'm looking at the GLSL 3.30 spec
<SGautam>
zid: core
xenos1984 has quit [Ping timeout: 246 seconds]
<zid>
puck yea obviously
xenos1984 has joined #osdev
<zid>
I'm saying in order to *make that true*, which it apparently *is not in practice*, you have to *add* code to the parser
<puck>
not sure on that actually
<zid>
comes down to design, but it be trivially true for some
<puck>
like, you could say "filtering globals with a certain name by type" is also adding code to the parser :p
<zid>
You already have to do that
<zid>
because there are float, vec2, vec3 etc versions of functions
<puck>
those are all the same type: function
<puck>
:p
<zid>
so identifier always to support having variants
<Hammdist>
if I can read sctlr_el1, does that mean I am in el1? if not, how to determine? thanks
dennis95 has joined #osdev
danilogondolfo has quit [Quit: Leaving]
<Hammdist>
ah it's with an mrs("CurrentEL")
<Hammdist>
it reads as 8, so I seem to be in EL2
<Hammdist>
which makes sense why would kexec not allow hypervisors to be executed
gabi-250 has quit [Remote host closed the connection]
<froggey>
error: linking with `x86_64-elf-ld` failed: signal: 10 (SIGBUS)
<froggey>
ld, please! I'm not even doing anything weird this time!
gildasio has joined #osdev
gabi-250 has joined #osdev
Jari-- has quit [Remote host closed the connection]
<zid>
froggey: It has cultural memory
Hammdist has quit [Quit: Client closed]
Hammdist has joined #osdev
<froggey>
it knows what I've done
ornx has quit [Ping timeout: 240 seconds]
ornx has joined #osdev
<sham1>
It sees the fear in your eyes
<ddevault>
installed ares on my laptop :D
<Ermine>
ddevault: so do you have networking?
<ddevault>
no
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gog has joined #osdev
duderonomy has joined #osdev
Hammdist has quit [Quit: Client closed]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xenos1984 has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
eddof13 has joined #osdev
m3a has joined #osdev
k0valski18891 has joined #osdev
goliath has quit [Quit: SIGSEGV]
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
valshaped74244 has joined #osdev
valshaped7424 has quit [Ping timeout: 250 seconds]
valshaped74244 is now known as valshaped7424
Hammdist has joined #osdev
<Hammdist>
after executing `msr vttbr_el2, x1` in qemu from address 0x40200048, the emulator jumps to address 0x200 which has nops there
<Hammdist>
somehow I wasn't expecting assignment to vttbr_el2 to have immediate effect
<Hammdist>
and why would it jump, even if the memory mappings were updated immediately?
<Hammdist>
ah maybe the page table must be page aligned
heat_ has quit [Ping timeout: 258 seconds]
heat has joined #osdev
hirigaray has joined #osdev
eddof13 has joined #osdev
terminalpusher has joined #osdev
<Hammdist>
setting the qemu machine type to raspi3b gets further
dennis95 has quit [Quit: Leaving]
nyah has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<geist>
if you want to track why exceptions happen, run qemu with `-d int`
<geist>
shows you exceptions as they happen
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
<heat>
mjg, fstat should be fast no?
<heat>
also dup > open I guess? but i wanted to make sure the refcounting = 0 was getting done properly
linearcannon has joined #osdev
vdamewood has quit [Ping timeout: 245 seconds]
sebonirc has quit [Ping timeout: 246 seconds]
sebonirc has joined #osdev
linear_cannon has quit [Ping timeout: 246 seconds]
<mjg>
fstat?
<mjg>
you for realzies
divine has quit [Ping timeout: 245 seconds]
<mjg>
it's tons of work
<mjg>
it would be faster to F_GETFD
<mjg>
or better yet, write a custom fcntl to keep pounding on lookup while within the kernel
<Hammdist>
what's the equivalent of mair_l2? I've set attributes on pages but now I realize I haven't set up the mair vector for l2
vdamewood has joined #osdev
<heat>
F_GETFD in freebsd has a lock
<heat>
how is fstat tons of work?
<heat>
/maybe/ it could be faster to read() on /dev/null, /maybe/
<mjg>
F_GETFD on freebsd sucks, news at 11
<mjg>
you don't take any locks to handle fstat?
<mjg>
and then copy all that data to userspace along with a smap trip to do it?
<mjg>
if you insists on a syscall, you can invoke something close to getppid in rate
<mjg>
which fstat is not
<gog>
qemu -d meow
* sham1
deposits fishy on gog's qemu instance
* mjg
sneaks in a quick hug
<gog>
o:
<gog>
so much love
<heat>
mjg, hard to safely implement F_GETFD lockless
<heat>
i ranted about that yesterday
* gog
prr and chomp fishy
gildasio has quit [Remote host closed the connection]
<heat>
linux does, for fcntl: if (!check_if_fd_is_alive()) /* lockless, RCU fget */ return -EBADF; switch(cmd) {...}
<heat>
and then in cmd they grab the lock and check the O_CLOEXEC bitmap
<mjg>
*getfd*?
<heat>
yes
<mjg>
it is beyond trivial
<heat>
it is not
<heat>
there's a race there
<mjg>
i may just do it for lulz
<mjg>
to spite you
<heat>
bro
<heat>
how is there not a race?
<mjg>
who said there is not
<mjg>
it is trivially fixable
<heat>
how?
<mjg>
sequence counters
<heat>
i guess
divine has joined #osdev
<heat>
but then you add more overhead to other paths
<mjg>
what paths
<heat>
and linoks people tell you off
<heat>
open paths
<mjg>
no
<heat>
dup paths
<mjg>
not true either
<mjg>
well not in frebsd
<mjg>
dup already has to do it
<heat>
afaik what you're suggesting is something like: fdtable->seq++; /* atomically? */
<mjg>
because of capsicum
<mjg>
what fucking fdtable bro
<mjg>
fd entry
<heat>
in the paths that modify
<heat>
huh?
<heat>
your fd entries arent just pointers?
<mjg>
no, because capsicum
<heat>
capsiCUM
<mjg>
entries are freaking big man
<heat>
get outta here
<heat>
shit kernel
<mjg>
i am agreed
<mjg>
first impelmentatin did not even do seqc
<mjg>
so fd lookup was racing against capability reads from said fd
<mjg>
interestingly there were real programs where this was breaking stuff
<heat>
in any case I think doing O_CLOEXEC may be trivial, just reuse the bottom bits of the struct file*?
<heat>
if you have them, that is
<mjg>
but then you have to mask it off for every load fro there
<mjg>
mr overhead
<heat>
wasnt linox already doing this shit for something else?
<mjg>
they have a dedicatd bitmap for cloexec
<mjg>
they do mask shit as flags for fput
<heat>
i know they have a bitmap for cloexec
<heat>
kinda the point
<mjg>
whacking the bitmap may be a sensible thing to do
<heat>
what? no
<heat>
way faster to walk through a bitmap in fork
<mjg>
hear me out LUSER
<heat>
than to go through the array
<heat>
erm
<heat>
walk through a bitmap in exec
<mjg>
bouncing the bitmap is part of the scalability problem
<mjg>
but indeed it may be this is not worth touching
<mjg>
so i just learned that BUG_ON and shit are always enabled
<mjg>
as in there is no config option to whack them
<heat>
i also have an rcu trace of the workload if you wanna look at that, its kinda nice
<mjg>
nah man i'm kind of tired
<heat>
I instrumented it all with nice tracepoints
<mjg>
careful, checking what's happening is anti geezer
<mjg>
may bite you once you get a job
<heat>
i need to add some rcu-ish capabilities to my creds stuff
<heat>
im still locking there
<mjg>
probably you don't
<mjg>
i already told you to do what everyone is doing and COW it
<heat>
yes i know
<heat>
that's why I said rcu-ish
<mjg>
cow is not in the same galaxy
<heat>
you're not in the same galaxy
<heat>
anyway these are solid wins and im very happy
<mjg>
what's the difference between a duck?
<heat>
i see my fancy performance work and my flamegraphs and my traces and im proud
<heat>
this is a sin but i am proud
<mjg>
i was proud of a thing once
<mjg>
then i got more clue
<mjg>
so... you are beating both open and netbsd right?
<mjg>
maybe some dragonfly?
terminalpusher has quit [Ping timeout: 246 seconds]
<heat>
i don't know, didn't test, probably?
<mjg>
just a suggestion
<mjg>
you do you
<heat>
i could bench against them but that takes effort
<heat>
and im all for no effort
<Hammdist>
can qemu give info on where the peripherals are mapped through the monitor interface? I'm having a hard time figuring out where the serial port is on the raspi3b emulated board
<Hammdist>
I try to write at an address based on where it should be in hardware but nothing happens
<heat>
info mtree?
<Hammdist>
ah thanks. so it should be there all right. maybe it needs initializing
<zid>
heat: what is spot in portugese, as in, acne
eddof13 has joined #osdev
<heat>
borbulha?
<Hammdist>
apparently it doesn't need initializing, according the qemu source code
<zid>
so the BIS has a borbulha faced youth apprentice?
<zid>
BfH*?
* zid
googles
<zid>
bofh
<zid>
wow they're still publishing those
<heat>
i guess
<zid>
are you sure you know portuguese
<heat>
pimply-faced -> borbulha faced
<heat>
sounds good to me
<zid>
you don't sound very confident
<zid>
heat: I have a borbulha right where my lip meets normal skin, it sucks
<heat>
'tis life
<heat>
but for instance chickenpox i've heard mancha (literal translation of spot) a lot more, vs borbulha
<bslsk05>
users.rust-lang.org: `ld` segfaults on getting the address of __GNU_EH_FRAME_HDR - help - The Rust Programming Language Forum
<froggey>
found my ld crash, somebody else ran into it
<froggey>
turns out ld crashes if you do &__GNU_EH_FRAME_HDR and it generates some specific kind of relocation, workaround is to get ld to rename the symbol