memset has quit [Remote host closed the connection]
memset has joined #riscv
crabbedhaloablut has joined #riscv
zjason`` is now known as zjason
naoki has quit [Quit: naoki]
Andre_Z has joined #riscv
Tenkawa has joined #riscv
q66 has quit [Quit: WeeChat 4.3.5]
q66 has joined #riscv
cousteau has joined #riscv
<cousteau>
I just ran `riscv32-unknown-elf-size main.elf` and got "text: 14403". How can the size of the instructions be an odd number?
<cousteau>
Or does `text` include something other than instructions?
<sorear>
it's not forbidden
<sorear>
use objdump to see the breakdown per section?
<cousteau>
I just ran readelf on the same file and I'm having a hard time interpreting the output. It ends in "section to segment mapping", with segment 00 (which I understand is "text") consisting of .vectors + .init + .text, which amounts to 12530, not 14403
<sorear>
"text" in `size` output is not a physical section or segment unless you're using a.out executables
<sorear>
the elf data model is richer than what size can express
<cousteau>
Well yeah, it's got sections
<sorear>
it's useful for quick comparisons but not much beyond that
<sorear>
I suspect it's adding together all sections (not segments) after grouping them by permissions
<cousteau>
I kinda assumed it was something like that. text = the program, data = the constants and variables (with an initial value) that are not hard-coded into instructions, bss = zero-initialized variables that get zeroed out at program startup
<sorear>
until well into this century "is this writable?" was considered more important than "is this executable?" so rodata is grouped with text by traditional executable formats
<cousteau>
sorear: well, the only three sections with AX flag according to readelf (or with X in general) are .vectors, .init, and .text
<sorear>
i686 and most other architectures from that era don't even distinguish between r-- and r-x permissions in hardware
coldfeet has joined #riscv
<cousteau>
But yeah, closer inspection of the section to segment mapping in readelf makes it obvious that the segments are unrelated to text/data/bss
* cousteau
checks the linker script
<sorear>
QMAGIC, etc
<cousteau>
Since it crams both .[s]data and .[s]bss into segment 02
<sorear>
segment numbers don't mean anything
<sorear>
you can reorder them without changing the meaning of an executable
<sorear>
the permissions, flags, and vaddr/size matter
<cousteau>
OK, so .vectors + .init + .text + .rodata = 14343. I'm still missing 60.
<cousteau>
Must be .eh_frame (that one's exactly 60)
<cousteau>
So basically all sections not marked as W
eightthree has quit [Ping timeout: 252 seconds]
eightthree has joined #riscv
JanC is now known as Guest6880
Guest6880 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
cousteau has quit [Read error: Connection reset by peer]
cousteau has joined #riscv
cousteau has left #riscv [Leaving]
psydroid2 has joined #riscv
<conchuod>
palmer: Yea, I think they did.
frkzoid has joined #riscv
freakazoid332 has joined #riscv
frkazoid333 has quit [Ping timeout: 252 seconds]
frkzoid has quit [Ping timeout: 276 seconds]
freakazoid332 has quit [Ping timeout: 276 seconds]
coldfeet has quit [Remote host closed the connection]
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #riscv
BootLayer has joined #riscv
ldevulder has quit [Quit: Leaving]
frkazoid333 has joined #riscv
frkazoid333 has quit [Read error: Connection reset by peer]
frkazoid333 has joined #riscv
vgtw has joined #riscv
dramforever has joined #riscv
<drewfustini>
palmer: sorry about [PATCH] clk: T-Head: Disable on 32-bit Targets
<drewfustini>
I had thought because the patchwork was clean it was okay
<drewfustini>
I'll start doing 32bit too. What other tests should I run locally in the future?
<drewfustini>
conchuod: is the solution for the sophgo problem to just wait a cycle between the bindings and the dts patches that reference them?
<conchuod>
Only if you're TI and like delaying.
<conchuod>
Otherwise, if you're sending PRs to both Arnd and Stephen, as was the case here IIRC, you can just put the binding headers on top of a -rc and use that as the base for your dts and driver patches.
<conchuod>
That's what I've done whenever I've been in that position.
<drewfustini>
But wouldn't it break if Linus pulls Arnd before Stephen?
<conchuod>
How?
<drewfustini>
If the dtsi references bindings header ?
<arnd>
drewfustini: the way conchuod described, the bindings are on both branches, so they each build correct
<drewfustini>
I assumed the bindings header would go through clk?
<conchuod>
Maybe my wording was not clear, the binding headers are in both branches.
<conchuod>
If you look at the thread palmer linked, there's an example in my mail.
<arnd>
drewfustini: it might break at runtime if the dt changes add a clock that becomes mandatory and the driver isn't there yet. Ideally any change to the dts should be backward-compatible and only add new functionality but for a brand new chip it does happen that the kernel no longer boots if you are missing an essential driver that wasn't needed before
memset has quit [Remote host closed the connection]
memset has joined #riscv
<conchuod>
Which will often happen when the first clock controller driver gets added - but I've completely soured on adding anything with only stub fixed-clocks that will be replaced later.
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #riscv
<drewfustini>
Thanks arnd and conchuod
<drewfustini>
I suppose one solution is to use integers in the clock properties until the next cycle?
<drewfustini>
I'm just worried about being a similar offender and want to make sure I do best practices
<conchuod>
Just build your own branch before sending a PR (or get lkp to build it for you) and it won't happen.
<arnd>
right, and try to use an early -rc as a base, not the latest at the time: if I have the soc/dt branch e.g. based on -rc2 but you send a PR based on -rc3, that creates an ugly back-merge. For normal branches I would just ask you to rebase and resend if that happens, but you can't rebase if the branch is shared with another tree
<palmer>
ya, just push stuff to next and it'll sort itself out ;)
<conchuod>
In this case, linux-next hid it cos it had both branches ;)
<drewfustini>
Okay, I'll be sure to look at the base of soc/dt
<drewfustini>
I did get my tree added to next for thead-dt-fixes and thead-dt-for-next.
<drewfustini>
I have not yet added anything to them yet. The SPI controller dts patch would be the first