Searched hist:5967 (Results 1 - 20 of 20) sorted by relevance
| /gem5/src/base/loader/ | ||
| H A D | dtb_object.hh | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | dtb_object.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | ecoff_object.hh | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | aout_object.hh | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | raw_object.hh | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | raw_object.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | aout_object.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | ecoff_object.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | elf_object.hh | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | object_file.hh | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | elf_object.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/arch/arm/freebsd/ | ||
| H A D | system.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/dev/pci/ | ||
| H A D | PciHost.py | diff 12474:31aaa43d1401 Fri Jan 22 10:40:00 EST 2016 Glenn Bergmans <glenn.bergmans@arm.com> arm: DT autogeneration - generate PCI node Enables automatic generation of Device Trees for RealView PCI host controllers. Note that some parts are more hard coded than you'd want, but this is due to the limited understanding the PCI host has of its configuration (i.e. it doesn't know all memory ranges). Fixing this, for now at least, went beyond the scope and intentions of the Device Tree generating code: use with care! Change-Id: I2041871e0eb4d04fb5191257c47dd38649d1c0cc Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5967 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/arch/sparc/ | ||
| H A D | system.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/arch/arm/linux/ | ||
| H A D | system.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/sim/ | ||
| H A D | process.hh | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | syscall_emul.hh | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | process.cc | diff 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/arch/x86/isa/decoder/ | ||
| H A D | two_byte_opcodes.isa | diff 5967:ff9203dd7608 Fri Feb 27 12:24:00 EST 2009 Gabe Black <gblack@eecs.umich.edu> X86: Fix a decoder bug and add in some missing instructions. |
| /gem5/src/dev/arm/ | ||
| H A D | RealView.py | diff 12474:31aaa43d1401 Fri Jan 22 10:40:00 EST 2016 Glenn Bergmans <glenn.bergmans@arm.com> arm: DT autogeneration - generate PCI node Enables automatic generation of Device Trees for RealView PCI host controllers. Note that some parts are more hard coded than you'd want, but this is due to the limited understanding the PCI host has of its configuration (i.e. it doesn't know all memory ranges). Fixing this, for now at least, went beyond the scope and intentions of the Device Tree generating code: use with care! Change-Id: I2041871e0eb4d04fb5191257c47dd38649d1c0cc Reviewed-by: Curtis Dunham <curtis.dunham@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5967 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
Completed in 225 milliseconds