valentin has quit [Read error: Connection reset by peer]
jeancf has joined #riscv
davidlt has quit [Ping timeout: 264 seconds]
KREYREEN has joined #riscv
SwitchOnFreenode has quit [Remote host closed the connection]
valentin_ has quit [Read error: Connection reset by peer]
valentin has joined #riscv
jeancf has quit [Ping timeout: 272 seconds]
clandmeter has joined #riscv
<dh`>
so I'm trying to make a riscv gcc config for os161
<dh`>
and the build failed in libgcc with "error: alias definitions not supported in this configuration"
<dh`>
this doesn't appear to be anything that should be os-specific in the configury
<jrtc27>
perhaps you should reconsider your choice of toolchain :)
<geist>
dh`: have you tried just a plain -elf triple? I've usually done that and it works well, unles you have specific triple customizations you want
<dh`>
the primary reason to have os161 configs is so that students building the toolchain for themselves have fewer opportunities to do it wrong
<dh`>
(and also so the os161 makefiles don't need tweaking all the time)
<geist>
hmm, well perhaps just customize it the minimum possible to copy the -elf selection in the configure files
<geist>
sounds like maye it's fouling up the multilib logic
<geist>
maybe one of the higher level configure things isn't selecting the right t-elf or whatnot file in gcc/config/riscv?
<dh`>
so the immediate problem seems to be that ASM_OUTPUT_DEF isn't defined anywhere in gcc/config/riscv
<dh`>
however it's not obvious why this is only breaking my config
<dh`>
it differs from the -elf one mostly by including some additional defs for os161 and by disabling some crtstuff
<jimwilson>
there is a default definition of ASM_OUTPUT_DEF in gcc/defaults.h, it is only used if SET_ASM_OP is defined, this is defined in gcc/config/elfos.h which almost all elf targets include
<jimwilson>
no one has tested any non-elf gcc riscv support as far as I know
<dh`>
I have elfos.h
<dh`>
hmm
<dh`>
aha
<jrtc27>
someone on risc-v international slack was asking about PE/COFF support the other day :')
<dh`>
the problem was #undef SET_ASM_OP cargo-culted from the mips config
<dh`>
I wish gcc configury were more declarative
<dh`>
someday dhcc will happen and then people can see how it ought to be done ;-)
<geist>
oh interesting. i wonder how the riscv PE stuff is done for uefi now? maybe objcopy from ELF?
Gravis has quit [Ping timeout: 252 seconds]
Gravis has joined #riscv
Gravis has joined #riscv
Gravis has quit [Changing host]
<sorear>
when I last looked at the PE spec it was really not set up to support anything other than EFI
<sorear>
and PE has 4-bit (!) relocation type fields, which are easy to run out of if that's not done very carefully
valentin has quit [Read error: Connection reset by peer]
valentin_ has joined #riscv
<jrtc27>
the current PE only has base relocations, not object only ones
<jrtc27>
ie dynamic vs static in elf parlance
<jrtc27>
AFAIK people just construct the headers manually in assembly
<jrtc27>
at least, that's what FreeBSD does
<xentrac>
ugh, efi
<cousteau>
oh no, bootloaders
<xentrac>
bootloaders can be better than efi
<xentrac>
like, literally everything else i've ever seen
<jrtc27>
sorear: 4 bits for base relocations, yes, but object only relocations have a full 2 bytes
<jrtc27>
ie it's a good thing they prelink everything at a preferred load address, because then you don't need so many dynamic relocation types...
<geist>
ah so it's set up such that the only real way to do it is to link to ELF and then convert
zjason has quit [Read error: Connection reset by peer]
zjason has joined #riscv
mhorne has quit [Ping timeout: 252 seconds]
riff-IRC has quit [Ping timeout: 272 seconds]
smartin has quit [Quit: smartin]
onoffon has joined #riscv
mhorne has joined #riscv
<TwoNotes>
Trying to use gdb-multiarch against QEMU, emulating RV64. When I try to connect them I get "bfd requires flen 8, but target has flen 0". What is BFD? What is FLEN? I have debugged other programa this way
<dh`>
bfd is 'binary format descriptor', the retargetability backend goo of binutils and gdb
<dh`>
flen, dunno
<TwoNotes>
Hmm. Used same linker script and toolchain as when this worked.
<jrtc27>
FLEN is the size of your floating-point registers
<jrtc27>
I guess it thinks your QEMU has no floating-point support and is unhappy about that
<TwoNotes>
Ah. That is a change. I specified march=rv64gc this time.
onoffon has quit [Quit: CU]
<TwoNotes>
When assembling
<jrtc27>
(FLEN defined in 12.1 F Register State of the unprivileged spec, FWIW)
<TwoNotes>
I will try going back to RV64im for now. Im not doing any flaoting now anyway
<dh`>
ah, that flen
<TwoNotes>
Ah, then was it.
<TwoNotes>
I will deal with that later
<TwoNotes>
I had mixed C and AS code, and the C compiler was putting out stuff suggesting it wanted to do float hings, which is why I changed to 'gc'
<TwoNotes>
I will omit the C code for now
<jrtc27>
floating-point should work just fine
<jrtc27>
unless you turn it off in QEMU...
<jrtc27>
then it'll probably not report it to GDB?
<TwoNotes>
So maybe it is the QEMU setting I should look at
<TwoNotes>
I am still working on very low level code for now - interupt dispatching etc. Doing it in AS is fine
<sorear>
march=rv64gc should go with mabi=lp64d
<jrtc27>
depends what you want
<jrtc27>
lp64 should *work* just less efficiently
<jrtc27>
should be orthogonal to this issue
<jrtc27>
TwoNotes: what's your qemu command line?
<xentrac>
'binary format descriptor' is a retronym for 'bfd'. what happened as i understand the story is that somebody at cygnus (probably gumby, i forget) wanted to make the binary backend stuff retargetable and stallman said it was way too hard and would complicate things a lot
<xentrac>
and the answer was 'look, it's not such a big fucking deal'
<dh`>
(I thought libbfd was older than cygnus, but maybe not)
<xentrac>
it might predate cygnus's formal incorporation
<jrtc27>
xentrac: arguably stallman was right, bfd is a mess and not very general, it's a very leaky abstraction that's mostly just a second copy of everything elf does
<xentrac>
jrtc27: maybe a file format standard would have been better than an api standard but oo was in vogue
<TwoNotes>
I even tried setting the gdb-multiarch architecture before doing the remote command, but same error
<dh`>
it's supposed to abstract over binary formats
<dh`>
it just doesn't do it that well
<TwoNotes>
Hmm. WHat is emulated clock speed in QEMU RV64? My serial output is garbage
neg has joined #riscv
<jrtc27>
configured baud rate is ignored
<jrtc27>
it's an emulator
<jrtc27>
IIRC
<TwoNotes>
Ok - its some other problem then
<jrtc27>
(uh, divisor even)
khem has joined #riscv
riff-IRC has joined #riscv
<cousteau>
...wouldn't that make it a simulator, not an emulator?
valentin has joined #riscv
valentin_ has quit [Read error: Connection reset by peer]
<jrtc27>
no
<TwoNotes>
I would not expect nanosecond accuracy in a software emulator. When I really needed to do that I used an oscilloscope and real hardware
<enthusi>
leah2: oh, thanks. Odd... did you order very early then maybe?
dobson has joined #riscv
Gravis_ has joined #riscv
Gravis has quit [Ping timeout: 264 seconds]
valentin has quit [Read error: Connection reset by peer]
valentin_ has joined #riscv
Gravis_ has quit [Quit: Murdered]
Gravis has joined #riscv
Gravis has quit [Changing host]
Gravis has joined #riscv
hendursaga has quit [Ping timeout: 252 seconds]
hendursaga has joined #riscv
Andre_H has quit [Ping timeout: 272 seconds]
clandmeter has quit [Changing host]
clandmeter has joined #riscv
cousteau has quit [Quit: Leaving]
emv has joined #riscv
emv has quit [Ping timeout: 272 seconds]
valentin_ has quit [Read error: Connection reset by peer]
valentin has joined #riscv
Gravis has quit [Ping timeout: 264 seconds]
theruran has quit [Quit: Connection closed for inactivity]
iorem has joined #riscv
valentin has quit [Read error: Connection reset by peer]