Am Mittwoch, 28. Februar 2007 schrieb Dennis Schridde:
> Am Montag, 26. Februar 2007 schrieb Dennis Schridde:
> > Am Montag, 26. Februar 2007 schrieb Per Inge Mathisen:
> > > On 2/26/07, Dennis Schridde <[EMAIL PROTECTED]> wrote:
> > > > I didn't do this yet, because backtrace_symbols(_fd) doesn't give
> > > > more usefull output than backtrace until you compile with -rdynamic.
> > >
> > > Then why don't we?
> >
> > Don't what? Compile with -rdynamic?
> >
> > It seems to be the opposite of -fvisibility=hidden:
> > -rdynamic
> >     Pass the flag -export-dynamic to the ELF linker, on targets that support
> > it. This instructs the linker to add all symbols, not only used ones, to
> > the dynamic symbol table. This option is needed for some uses of "dlopen"
> > or to allow obtaining backtraces from within a program.
> >
> > Big symbol tables usually make the program load slower. Additionally this
> > functionality can easily be reproduced with addr2line, so I don't see a
> > reason to create any load on the user end.
> > And just use some fancy compile switches so we can do something on the
> > user end, which also could be done on the developer end easily, doesn't
> > seem very good to me.
> >
> >
> > There is an example which doesn't use any C runtime functions which may
> > be unsafe: http://www.codeproject.com/debug/XCrashReportPt3.asp
> > This is using the Windows API, though...
> > Maybe there is something similar for Linux and MacOS, which we could
> > utilize...
> >
> > > > For reading these binary blobs you need to tool I sent a while ago. I
> > > > attached it again.
> > >
> > > This should definitely be in the repository if it is required to read
> > > files produced by Warzone. In the tools/ directory, perhaps?
> >
> > K, I'll commit it. It can be deleted when we output plaintext files...
>
> Just looked into
> http://www.unix.org/version3/ieee_std.html (the list of signal safe
> functions is also included in the signal manpage).
XSH / POSIX function standard -> chapter 02, 04
>
> According to POSIX write() is signal safe, so we could use that instead of
> fwrite() (which is not guaranteed to be safe).
> We would have to write an own replacement of sprintf(), which doesn't use
> malloc(), but that shouldn't be too difficult if we use a fixed string
> length.
>
> --Dennis


Attachment: pgpzP6RbRjvQy.pgp
Description: PGP signature

_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev

Reply via email to