[Crash-utility] Re: EFBIG with gdb - to you hack gdb to pass O_LARGEFILE in the files open() flags?

[Pete/Piet Delaney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave Anderson wrote:
| Pete/Piet Delaney wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Hi Dave:
|>
|> I was wondering why gdb isn't having a problem with the crash file
|> being too big when started with crash yet when handing the
|> vmcore directly to gdb it gets an error while opening the file EFBIG.
|
| Because the embedded gdb module in crash doesn't have a clue
| about dumpfiles.  It's invoked internally simply as "gdb vmlinux"
| in order to get the symbol values, debuginfo data, etc.

I just thought, gdb can't get thread info from a core file
like kgdb can via the simulated ptrace or /proc interface.
There are other problems; for example ddd is passing a -q
option to gdb and crash doesn't know what to do with it.

I don't suppose anyone has hacked ddd to access gdb via crash.
There's a --debugger option to ddd but as I recall with crash
gdb commands need to be prefixed with 'gdb' so the data browser
wouldn't know to do that.

- -piet

|
| When you bring up gdb on just a binary executable you can still
| issue gdb commands that in turn generate read commands from the
| the executable.  But one of the many hacks to the embedded gdb module
| is to hijack any read attempts, and pass them back up to the
| crash-based module for resolution.
|
| Dave
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH0emIJICwm/rv3hoRAgKRAJ0d0BTMFl0LB04CI+5oevgDnNRISwCdGyTc
MTsqK7edWFpCGTo1Y6mKNPU=
=LgRQ
-----END PGP SIGNATURE-----