<apelete>
I built 3.9 with the following debug options for kgdb:
<apelete>
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
<apelete>
CONFIG_KGDB=y
<apelete>
CONFIG_KGDB_SERIAL_CONSOLE=y
<apelete>
CONFIG_MAGIC_SYSRQ=y
<apelete>
CONFIG_CONSOLE_POLL=y
<apelete>
CONFIG_FRAME_POINTER=y
<apelete>
CONFIG_KALLSYMS=y
<apelete>
CONFIG_KALLSYMS_ALL=y
<apelete>
but the gdb backtrace output is almost empty, preventing me to debug anything
<apelete>
viric: you seem to get a correct gdb behaviour, any idea about what I am missing ?
<viric>
you need a vmlnux with debug info
<viric>
vmlinux
<viric>
there is a CONFIG_DEBUG or so
<apelete>
viric: I flashed the uImage to NN and launched gdb with vmlinux indeed, but it doesn't help
<viric>
but your vmlinux needs debug info.
<apelete>
viric: forgot to mention it, I also have:
<apelete>
CONFIG_DEBUG_INFO=y
<apelete>
CONFIG_DEBUG_KERNEL=y
<apelete>
I really don't see what I'm missing :-(
<viric>
does gdb attach fine?
<apelete>
yes
<viric>
Are you using a mips gdb? :)
<apelete>
ha...
<apelete>
no.
<viric>
here it is :)
<apelete>
viric: I'm using my debian flavoured x86 gdb. how can I get a mips gdb ?
<viric>
ask your toolchain provider
<viric>
those who gave you a gcc for mips, should be able to give you a gdb for mips
<apelete>
that's the Qi Hw guys :-). will a take a look at the nanonote wiki then
<apelete>
viric: I always forget about the toolchain, been used to debug x86 hardware I guess. thanks for the tip, will let you know if it works
<whitequark>
[insert a rant about the unnecessity of target-specific toolchains]
<apelete>
whitequark: how can target-specific toolchains be unnecessary since we already need them ? :-)
<whitequark>
apelete: other toolchains *cough*LLVM+LLDB*cough* don't need to be recompiled for each target.
<apelete>
whitequark: wow, are you serious ? didn't know it was even possible oO
rz2k has quit []
<whitequark>
it is trivial, if you don't abuse macros and global variables and so on
<apelete>
never used anyhting else than gcc+gdb, I didn't know LLVM+LLDB had such an advantage
<apelete>
s/anyhting/anything/
<qi-bot>
apelete meant: "never used anything else than gcc+gdb, I didn't know LLVM+LLDB had such an advantage"
<roh>
llvm and lldb do not support that much platforms at all, so there is no point
<whitequark>
well. LLVM is a mature compiler. LLD (its linker) is definitely not production-quality. LLDB is halfway: it's the default OS X debugger, but it severely lacks support for targets interesting to us
* whitequark
is still using gdb
<whitequark>
roh: llvm supports all major platforms well though
<whitequark>
x86, arm, various mipses
<roh>
whitequark: well.. cross?
* apelete
should read more about toolchains and compilers...
<whitequark>
roh: hm?
<roh>
whitequark: last time i watched somebody try using llvm to compile stuff for arm it was like 2 days before he gave up
<whitequark>
llvm has no notion of cross-compiling, you just select the triple and options and that's it
<whitequark>
not sure when was that. it's incredibly easy, both in clang and for your own frontend
rz2k has joined #qi-hardware
jekhor has quit [Ping timeout: 256 seconds]
<roh>
whitequark: the result was, it compiled broken binaries on x86, different ones when run on amd64, and only correct ones run on arm. the cross part was badly broken
<roh>
about ~1year ago in winter
<roh>
the target was some lpc something arm7/cortex m0 mcu
<roh>
ah.. and yes.. all the mcu targets are missing anyhow
<whitequark>
roh: I can just say that 3.2/3.3/3.4 which I use together with my compiler generate working code for x86/arm with no problems
<whitequark>
I can't elaborate on his problem without further details
<roh>
whitequark: ever tried non-linux targets?
<whitequark>
sure, my main target is baremetal cortex-m3
<roh>
nice to hear that works finally
<roh>
to be fair, i stopped even looking at llvm when i learned about how half-done it was.
<whitequark>
clang "almost" compiles kernel on x86/arm, "almost" meaning there is less than a dozen of patches which kill various horrible gcc extensions pending merge
<roh>
i know compilerbugs from gcc well, but usually you need to do ugly shit to provoke them
<roh>
well.. most gcc extensions used in the kernel make lots of sense to me. i woulnt know any other way to write it down less ugly
<whitequark>
roh: you may want to revise that. clang+llvm are very good (on par with gcc) on major targets in my experience. lld/lldb are indeed half-done, though that changes.
<whitequark>
(gcc extensions) it's not most of them which cause problems, but a few really horrible ones
<roh>
whitequark: i use not only major targets. is there avr already?
<whitequark>
no
<whitequark>
until recently there wasn't good multiple address space support. from 3.4 onwards it's simple
<roh>
i see.. well.. maybe i should revisit it.
<whitequark>
imo the main advantage of llvm is that it has very simple and clean architecture (not just compared to gcc). it's both easy to write *a* codegen, and a *good* codegen
<roh>
given that somebody finds nicer replacement for gcc extentsions
<apelete>
will try it tonight, when I get back from work :-)
<roh>
writing everything in k&R c would not only be madness, it would look ugly, and make code completely unmaintainable.. which for sure is not the goal
<whitequark>
roh: it supports vast majority of gcc extensions, even gcc inline assembly
<roh>
ah. thats one way of 'solving' this.. i hoped for something less ... gcc-esque ;)
<whitequark>
the ones which won't work are target-specific ones which do not map at all to LLVM architecure, say pinning variables to registers
<whitequark>
well it has to be compatible with existing code... who wants n+1 standards?
<roh>
whitequark: thats only for platforms linux works on, which is a multiple of fbsd. there are much more devices out there. to small for linux, but not for widespread use.
<roh>
bigger than werners 8051 ;)
<whitequark>
sure
<whitequark>
but that's at least a solid metric instead of vague promises :)
<roh>
my point being.. everybody kicks on gcc.. but yet it is still not replaceable. only SOME of its uses are
<roh>
still gcc has helped us all a lot in the last 2 decades
<whitequark>
true
<wpwrak>
more like 2.5 if not more :)
<wpwrak>
anybody remembers when the big commercial unices started to "unbundle" compilers ? that was when gcc really rose to power
<roh>
yup. so i guess from my personal pov there would be 2 milestones. one would be openwrt adding it as a second compiler, one would be working avr support.
<roh>
but as long as that doesnt happen (openwrt needs mips working properly) i guess i will stay true to my gcc for now ;)
<wpwrak>
plan B: sneak into atmel HQ, delete all the AVR files, burn the backups, then see how long it takes them to switch to ARM :) (it may be more of a challenge for marketing than for the engineers)
<roh>
wpwrak: arm sucks at the scales they build cpus
<whitequark>
roh: there's a lot of mips activity in llvm judging by ML (I don't build mips things though)
<wpwrak>
in what sense ?
<roh>
wpwrak: with an arm you cannot wiggle a gpio at 1/2 of the cpuclock.
<wpwrak>
weeeellll...
<whitequark>
roh: you can on some chips :)
<roh>
wpwrak: smaller cores, simpler design than arm, much less levels of bus shit etc.
<wpwrak>
i'm not even sure this is true. e.g., look at freescale's FGPIO
<roh>
last time i checked all arms i looked at, had a bus between gpio and core.
<wpwrak>
and then, atmel crawls at something like 8 MHz in an environment in which an ARM happily does at least four times that speed.
<roh>
if its ahb or whatever doesnt matter. too slow.
<whitequark>
do you need to bitbang things at >50mhz?
<roh>
wpwrak: bullshit.. 8mhz is slow for these.. the avr32 go up to high 2 digit numbers by default and the small old ones to 20 or 25
<whitequark>
because 50mhz is the fastest gpio hw can go, and I'm pretty sure stm32f1 can do that, but I can verify for you if you want
<roh>
whitequark: usually not. but everybody who needed to speak onewire (the ti crap) withz an arm once and with an avr, knows that its MUCH easier and less work to get the timing jitterless on an avr
<wpwrak>
"The GPIO is multi-ported and can be accessed directly by the core with zero wait states"
<wpwrak>
not sure how many cycles this means in the end, but it ought to be fast
<roh>
sbi is one cycle. thats why avr is nice. nearly all instructions are one cycle
<wpwrak>
roh: (avr, fast) 20 MHz ... at 5 V :)
<wpwrak>
whitequark: stm32 is way too powerful for that comparison ;-)
<whitequark>
roh: I see, it's true that jitter will be harder to remove
rz2k has quit []
<wpwrak>
but try the freescale kinetis series. they seem pretty decent, though somewhat overlooked
<roh>
wpwrak: if you need faster, maybe you chose the wrong cpu. i use them a lot for controlling work, where arm or so would be much more work to get the soc running. sleeping most of the time.. doing complex triggers etc.
<wpwrak>
and they're actually cheaper than avrs ;-)
<roh>
wpwrak: maybe. but 1$ difference doesnt matter if i get the work done in half the time
<whitequark>
roh: not sure what you need to "get the soc running". stm32f1s require literally zero initialization
<roh>
there is a reason for arduino using avr for most of their platforms
<roh>
whitequark: external hardware, bootcode
<whitequark>
one line of it to enable gpios. another two lines to switch to crystal. it's actually harder to muck with the option bytes on avr
<wpwrak>
yes, getting an arm running is a bit of a hassle. what's basically missing is the equivalent of avr-libc. i have high hopes for libopencm3, maybe with newlib, in that regard.
<whitequark>
wpwrak: cmsis?
<whitequark>
roh: which external hardware? avrs and arms need a bypass cap and an oscillator
<wpwrak>
whitequark: good luck with the on-chip peripherals :)
<whitequark>
which bootcode? avrs require a programmer, cortexes have swd, which is essentially same thing
<roh>
whitequark: not neccessarily. there is a 8mhz rc inside and also a pll if needed
<whitequark>
roh: on both of them
<wpwrak>
of course, you can use stm's peripheral lib ...
<whitequark>
wpwrak: imo all vendor libs suck, hw companies shouldn't ever attempt to write software
<roh>
ive used stm32 recently. nice for an arm, but way more complicated
<wpwrak>
that seems to be good advice :)
<roh>
whitequark: ack.
Jay7x has quit [Ping timeout: 248 seconds]
<roh>
about the "hw companies shouldn't ever attempt to write software"
<roh>
thats even true for intel and co.
<whitequark>
ACPI+EFI
* whitequark
shudders
<roh>
whitequark: not even that. check out your network drivers
<whitequark>
roh: wired or wireless?
<roh>
both
<whitequark>
iwlwifi is pretty horrible indeed. still better than broadcom though
<roh>
e1000 and iwlwifi both already had bad bugs
<roh>
in hw as in sw
<whitequark>
it has power management disabled by default
<whitequark>
which is telling
<roh>
acpi and efi are a multi-vendor-crime
<whitequark>
also it only works well for me with swcrypto=1 which is also telling
<whitequark>
(efi) before efi, i thought bios was bad. nope, it actually was an excellent, well-designed and thought out piece of software
<roh>
*g*
<whitequark>
a guy i know bricked an efi intel board and recovered it in an email conversation with intel
<wpwrak>
and then they hired beavis and butthead ... "let's break something"
<whitequark>
when he explained how he did it they offered to hire him
<wpwrak>
;-))
<whitequark>
perhaps efi is just a very contrived way to interview candidates
<roh>
ever went to school? thats not where engineers come from!
<whitequark>
roh: I could be a bioengineer
<roh>
i guess its just statistical errors now (having engineers) and when you find one, you try to hire em.
<wpwrak>
reminds me of the old joke about programming languages. (obfuscated) C programmer proudly shows his program to colleagues and asks "can you tell what it does ?". APL programmer shows his program and asks "can you PLEASE tell me what it does ?"
<whitequark>
wpwrak: hahaha
<larsc>
:)
<roh>
hrr
<whitequark>
roh: good for employment!
* larsc
develops software for a hardware company :/
<roh>
larsc: as a freelancer?
<larsc>
as a employee
<roh>
i think its only getting dangerous as long term employee
<larsc>
almost two years now
<roh>
since that makes you (usually) blind to the developments of the direct competition, their solutions etc... but knowing you are a hacker i guess not even your boss could hinder you reading also different datasheets
<whitequark>
roh: wait, why would anyone *want* to hinder people on that?
<roh>
e.g. on the intel, amd, nvidia stuff.. you see they have basically the same solutions to complex problems on their cpus, and all name it differently, have different parameter settings on these features etc.. but in the end... it doesnt matter how you call it.
<roh>
whitequark: intel seems to do that. atleast i know of no other way to write that stupid code.
<roh>
also it makes designing new subsystems pain, when you have no clue what your other developerfriends would need to have for an interface for the competitions hardware
<larsc>
I don't think not reading datasheets for other devices correlates to writing bad code
<roh>
larsc: it does because it makes you not see different designs and hardware layouts. you only see THE company flavour. that is what makes bad designs. blindness by too much of the same
<roh>
you know the sentence 'den wald vor lauter baeumen nicht sehn'?
<whitequark>
offtopic: it's an exactly same idiom in russian (and apparently english)
<roh>
funky
<larsc>
now we are talking about bad design
<larsc>
you can still write good code for a bad design
<larsc>
it's different layers
<whitequark>
most code by hw vendors I've seen was written like an afterthought
<whitequark>
"yeah, and now let's cobble some procedures together to configure our perfect core"
<whitequark>
said to a first-year intern
dos1 has joined #qi-hardware
<roh>
larsc: i'd rather have code written by somebody with access to documentation and hardware, than by somebody within the vendor who writes only drivers for that one vendors from time to time.
<roh>
usually it ends up with 'the guy who gets documentation access has written 10 drivers for 5 vendors and knows his framework'
<roh>
compared to 'the guy from the vendor is learning how to write his first kerneldriver ever from a book now'
<roh>
sure. there are good and bad examples for both ends of the spectrum. there is what ive seen live to often
<larsc>
If only people who already have already written 10 drivers get to write drivers, you'll never get new people to write drivers
<whitequark>
you probably shouldn't ship drivers written by complete novices without any modification though
<larsc>
'proper code review' is the catchphrase here
<roh>
larsc: true. but i guess you know what i mean. the 10 drivery already guy is a freelancer or short time employee on project basis
<roh>
the in-house coder is very often a student of some it foo and then gets to do that because he was ne only one not in holiday when they searched for a c-coder inhouse
<roh>
same is true for non-linux platform drivers as well.. i can show you a few examples when we meet at some point (win32 driver sources
<larsc>
I'm not even sure I want to see that ;)
<roh>
code review. nice idea. never seen that at a hw vendor.(yet)
<roh>
larsc: hrhr. true
<larsc>
we do code review
<larsc>
or well I do code review
<larsc>
;)
<roh>
hehe.. where you working at?
<larsc>
Analog Devices
<roh>
nice. also i must say, i havent heard anything bad.. which is a good sign in that business i guess
<roh>
can you tell what kind of devices you usually write drivers for there?
<larsc>
and due to good design we are able to reuse the same driver for multiple devices
<roh>
i guess thats where you differ to the typical inhouse coder already. they seem not even to care for something like that (code reuse)
<larsc>
I'm makeing myself obsolete (like any good engineer ;) )
<roh>
:)
<wpwrak>
(driver reuse) gcc -DADP8861 -c lars.c
<wpwrak>
roh: oh, but they do. they take the vendor package, make a copy, and use it to death. then the product ships and they never touch the code again.
FDCX_ has quit [Ping timeout: 264 seconds]
<roh>
wpwrak: exactly. thus it never gets reviewd, debugged, fixed, or security-patched
xiangfu has quit [Ping timeout: 264 seconds]
pcercuei has joined #qi-hardware
<whitequark>
I really wish LLVM compiled faster
* whitequark
probably spends half of his time compiling LLVM these days
<larsc>
are you compiling with gcc or with llvm? ;)
<whitequark>
depends
<whitequark>
the debian package prefers gcc
<whitequark>
though by now, the time spent compiling it would probably be bigger than time required to figure out how to adjust the package
<pcercuei>
compiling mipsel-linux-llvm? :)
<whitequark>
pcercuei: arm-none
<whitequark>
well, there's no such thing as cross-llvm, but I use it for arm-none-eabi.
<wpwrak>
"Another refreshing feature of OSv is that is written in C++." how boring. why not C#, Go, don't apple have any hip new language ? and where's Cloud-Ready Parallel Object-COBOL when we need it ?
<wpwrak>
though things seem to be moving at breakneck speed in the COBOL world. last thing i heard, they relaxed the format of the punch cards. a daring move for sure.
<whitequark>
... which is precisely, down to every word, what you asked for. :D
<Freemor>
wpwrak: I still have nightmares of bubbling in: 02 filler pic ...
<Freemor>
and waiting in terrified anticipation for the card reader to mangle and jam on sone card in the middle of the deck
xiangfu has quit [Ping timeout: 264 seconds]
<wpwrak>
too cool ;-) reality mimicking and even mocking sarcasm :)
<Freemor>
lol
<whitequark>
larsc: though charliesome is generally a good fellow, that's a joke project
<wpwrak>
(netcobol) "modernize your indexed file systems". why do i have the mental image of a stone age businessman shouting this into a cave ?
<whitequark>
lol
* Freemor
feels old
xiangfu has joined #qi-hardware
<Freemor>
but then 48 is like 100K in computer years
<viric>
Freemor: you must be one of those who invented the computers
<viric>
:)
* whitequark
. o O ( EWD )
<wpwrak>
hmm, a ~1965 model. that would be about 1 petacycle at the computer technology of that time
<Freemor>
no, no, just got started on them bac when they ran on wood, 300 baud ruled (with 110 baud as a fall back for dirty lines), and things lije zip, gif, jpg, etc weren't invented yet.
<wpwrak>
who needs ZIP if you have ARC ?
<Freemor>
lol
<wpwrak>
and who needs TCP/IP if you have kermit and xmodem ? well, things got *really* fancy, when "term" appeared. more than one data stream over the same (!) line
<Freemor>
i miss xmodem (in that naustalgic don't really remember how bad it was kinda way)
<Freemor>
before that all we had was the equivelent of cat foo > /dev/ TTyS0 and pray
<viric>
I remember the choice xmodem, ymodem, zmodem.
<viric>
was zmodem the best?
<Freemor>
yep
<Freemor>
had things like resuming a failed transfer and better thru put
<viric>
I remember I was reverse engineering the cool interlnk.exe/intersvr.exe, to implement a linux side
<viric>
Freemor: I remember zmodem resisting errors
<Freemor>
yep
<Freemor>
zmodem was nice
* Freemor
still has a 56k v42bis full hardware modem around
<Freemor>
no acoustic coupler tho :)
lekernel_ has joined #qi-hardware
lekernel has quit [Read error: Connection reset by peer]
FDCX_ has joined #qi-hardware
jekhor has quit [Ping timeout: 264 seconds]
wej has quit [Ping timeout: 245 seconds]
dos1 has quit [Quit: Kabum!]
dos1 has joined #qi-hardware
dos1 has quit [Read error: Connection reset by peer]
dos11 has joined #qi-hardware
dos11 has quit [Read error: Connection reset by peer]
dos1 has joined #qi-hardware
dos1 has quit [Read error: Connection reset by peer]
dos1 has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
dos11 has joined #qi-hardware
dos1 has quit [Ping timeout: 276 seconds]
<whitequark>
I know a guy who still uses zmodem
<whitequark>
zmodem is at least two times older than him
WielkiTost has joined #qi-hardware
dos11 has quit [Ping timeout: 248 seconds]
WielkiTost is now known as dos1
<viric>
whitequark: retro trend
<whitequark>
viric: he wanted to upload firmware to an fpga via uart or something
<viric>
:)
rz2k has joined #qi-hardware
<whitequark>
argh, I just bricked a completely new jlink clone
<cde>
how?
<viric>
with ruby?
<whitequark>
turned it on and ran segger's gdbserver
<whitequark>
it attempted to automatically update the firmware. that NEVER works.
<cde>
you gdbserver tries to update the firmware? wierd
<whitequark>
that's how jlink tools work
rz2k has quit [Read error: Connection reset by peer]
rz2k has joined #qi-hardware
rz2k has quit [Read error: Connection reset by peer]
rz2k has joined #qi-hardware
jekhor has joined #qi-hardware
<apelete>
viric: you were right about this morning, using the gdb coming from the toolchain and built for mips target solved it